From: Patrick C. <ph...@ou...> - 2009-08-25 15:56:05
|
Hi all. I read somewhere that mceusb gen1 devices (045e:006d) can't transmit using lirc. Is this still correct? If so, can someone explain to me what efforts have been made in that area and maybe where we've become stuck? In my own efforts to make it work, I've noticed that these lines of code (drivers/lirc_mceusb/lirc_mceusb.c cvs revision 1.44) seem to totally BREAK transmission: 1170 request_packet_async(ir, ep_out, init2, 1171 sizeof(init2), MCEUSB_OUTBOUND); If I remove that statement, I get some transmission through the blaster/dongle. (I removed this code statement based on what usb snoopy sees in Windows). The problem is, though, if I blast to another mceusb receiver in mode2, I receive only the initial fraction of the transmission (and more importantly, the target device does not react). To quantify that statement: I'm transmitting a Panasonic space_encoded command. My lircd.conf snippet is at the end of this message. I should be transmitting 6 data bytes. That's 48 data bits, which is 96 ir pulse/space transmissions. Adding 4 bytes of ir protocol overhead for "header" and "ptrail", that's an even 100 pulses/spaces, which implies 100 bytes transmission sent to the mceusb, (not counting the mceusb overhead of the "9f 08 06" initial command, "84" commands sent before every 4-byte pulse/space data block, and final "80" command). In short, mode2 gets 100 lines of output from my actual remote control, and gets only the first 40-48 lines from the lirc/mceusb trying to replicate those 100 lines. So anyone have any ideas? Thanks, Patrick begin remote name viera bits 24 flags SPACE_ENC eps 30 aeps 100 header 3456 1728 frequency 37000 one 432 1296 zero 432 432 ptrail 432 pre_data_bits 24 #pre_data is 3 bytes: vendor1, vendor2, device pre_data 0x400401 gap 74150 toggle_bit_mask 0x0 begin codes #codes are 3 bytes: subdevice, function, checksum KEY_POWER 0x00BCBD end codes end remote |
From: Jarod W. <ja...@wi...> - 2009-08-25 19:16:22
|
On Aug 25, 2009, at 11:35 AM, Patrick Calhoun wrote: > Hi all. > I read somewhere that mceusb gen1 devices (045e:006d) can't transmit > using lirc. Is this still correct? Yes. > If so, can someone explain to me > what efforts have been made in that area and maybe where we've > become stuck? I added support for the first-gen device to the second-gen driver. The original driver never had any transmit support, while the second-gen one does. I was hoping, but not expecting, that we'd add transmit support for free, but alas, no dice. It obviously requires some amount of change to transmit with the first-gen device, and I simply haven't had the time or impetus to look to see what needs doing. > In my own efforts to make it work, I've noticed that these lines of > code > (drivers/lirc_mceusb/lirc_mceusb.c cvs revision 1.44) seem to totally > BREAK transmission: > > 1170 request_packet_async(ir, ep_out, init2, > 1171 sizeof(init2), MCEUSB_OUTBOUND); > > If I remove that statement, I get some transmission through the > blaster/dongle. (I removed this code statement based on what usb > snoopy > sees in Windows). > The problem is, though, if I blast to another mceusb receiver in > mode2, > I receive only the initial fraction of the transmission (and more > importantly, the target device does not react). > > To quantify that statement: > I'm transmitting a Panasonic space_encoded command. My lircd.conf > snippet is at the end of this message. > I should be transmitting 6 data bytes. > That's 48 data bits, which is 96 ir pulse/space transmissions. > Adding 4 bytes of ir protocol overhead for "header" and "ptrail", > that's > an even 100 pulses/spaces, which implies 100 bytes transmission sent > to > the mceusb, (not counting the mceusb overhead of the "9f 08 06" > initial > command, "84" commands sent before every 4-byte pulse/space data > block, > and final "80" command). > > In short, mode2 gets 100 lines of output from my actual remote > control, > and gets only the first 40-48 lines from the lirc/mceusb trying to > replicate those 100 lines. > > So anyone have any ideas? Well, the first thing I was planning to do was try transmitting under Windows while snooping the traffic to see what packets were sent, then work from there... I got as far as plugging the thing into my laptop briefly while booted in Windows, saw that it loaded drivers, and that was as far as I got. If you've got snoops, feel free to hit me with them, and I can try to make heads or tails of them. -- Jarod Wilson ja...@wi... |
From: Patrick C. <ph...@ou...> - 2009-08-28 23:58:58
Attachments:
mceusb_gen1_xmit.diff
|
Jarod Wilson wrote: >> (drivers/lirc_mceusb/lirc_mceusb.c cvs revision 1.44) seem to totally >> BREAK transmission: >> >> 1170 request_packet_async(ir, ep_out, init2, >> 1171 sizeof(init2), MCEUSB_OUTBOUND); >> > > Well, the first thing I was planning to do was try transmitting under > Windows while snooping the traffic to see what packets were sent, then > work from there... I got as far as plugging the thing into my laptop > briefly while booted in Windows, saw that it loaded drivers, and that > was as far as I got. If you've got snoops, feel free to hit me with > them, and I can try to make heads or tails of them. > How about I do the grunt work and give you a patch instead? -Patrick |
From: Jarod W. <ja...@wi...> - 2009-08-29 03:17:46
|
On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: > > Jarod Wilson wrote: > > Well, the first thing I was planning to do was try transmitting under > > Windows while snooping the traffic to see what packets were sent, then > > work from there... I got as far as plugging the thing into my laptop > > briefly while booted in Windows, saw that it loaded drivers, and that > > was as far as I got. If you've got snoops, feel free to hit me with > > them, and I can try to make heads or tails of them. > > > How about I do the grunt work and give you a patch instead? That's always VERY much appreciated. :D I'd suspected it might end up being a fairly trivial patch, but not *that* trivial. I was thinking we might have to deal with split outbound buffers similar to the contortions that have to be done for receiving, glad to see that's not the case, just some initialization differences. Good work! I'll give it a quick test here w/my own gen1 transceiver, and will then go ahead and merge it. For good measure, Can you add a developer's certificate of origin (Signed-off-by:) line for me? Just replying to this email w/it is sufficient. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-08-29 19:16:46
|
On Friday 28 August 2009 23:17:23 Jarod Wilson wrote: > On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: > > > > Jarod Wilson wrote: > > > Well, the first thing I was planning to do was try transmitting under > > > Windows while snooping the traffic to see what packets were sent, then > > > work from there... I got as far as plugging the thing into my laptop > > > briefly while booted in Windows, saw that it loaded drivers, and that > > > was as far as I got. If you've got snoops, feel free to hit me with > > > them, and I can try to make heads or tails of them. > > > > > How about I do the grunt work and give you a patch instead? > > That's always VERY much appreciated. :D > > I'd suspected it might end up being a fairly trivial patch, but not > *that* trivial. I was thinking we might have to deal with split > outbound buffers similar to the contortions that have to be done for > receiving, glad to see that's not the case, just some initialization > differences. Good work! I'll give it a quick test here w/my own gen1 > transceiver, and will then go ahead and merge it. For good measure, > Can you add a developer's certificate of origin (Signed-off-by:) line > for me? Just replying to this email w/it is sufficient. Hrm. I still don't seem to be getting anything transmitted by my own 1st-gen transceiver. It *could* be that the transmitter cable/led I hooked up to it isn't compatible, but its from a 2nd-gen transceiver, and works fine there (I don't have the original transmitter parts around here anywhere). Does looping back to your 1st-gen transceiver result in irw picking up the transmitted key codes? -- Jarod Wilson ja...@wi... |
From: Calhoun, S. P. <ph...@ou...> - 2009-08-29 19:21:14
|
On Aug 28, 2009, at 10:17 PM, "Jarod Wilson" <ja...@wi...> wrote: > On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: >> >> Jarod Wilson wrote: >>> Well, the first thing I was planning to do was try transmitting >>> under >>> Windows while snooping the traffic to see what packets were sent, >>> then >>> work from there... I got as far as plugging the thing into my laptop >>> briefly while booted in Windows, saw that it loaded drivers, and >>> that >>> was as far as I got. If you've got snoops, feel free to hit me with >>> them, and I can try to make heads or tails of them. >>> >> How about I do the grunt work and give you a patch instead? > > That's always VERY much appreciated. :D > > I'd suspected it might end up being a fairly trivial patch, but not > *that* trivial. I was thinking we might have to deal with split > outbound buffers similar to the contortions that have to be done for > receiving, glad to see that's not the case, just some initialization > differences. Good work! I'll give it a quick test here w/my own gen1 > transceiver, and will then go ahead and merge it. For good measure, > Can you add a developer's certificate of origin (Signed-off-by:) line > for me? Just replying to this email w/it is sufficient. Sure: Regarding the patch I sent last night... Signed-off-by: Patrick Calhoun <ph...@ou...> 2009-08-29 I will say that transmitter 2 works as expected, but transmitter 1 only seems to fire for me when both transmitters are selected, not solo. -Patrick > > -- > Jarod Wilson > ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-08-29 19:55:43
|
On Saturday 29 August 2009 15:20:54 Calhoun, Sean P. wrote: > > On Aug 28, 2009, at 10:17 PM, "Jarod Wilson" <ja...@wi...> wrote: > > > On Friday 28 August 2009 20:01:20 Patrick Calhoun wrote: > >> > >> Jarod Wilson wrote: > >>> Well, the first thing I was planning to do was try transmitting > >>> under > >>> Windows while snooping the traffic to see what packets were sent, > >>> then > >>> work from there... I got as far as plugging the thing into my laptop > >>> briefly while booted in Windows, saw that it loaded drivers, and > >>> that > >>> was as far as I got. If you've got snoops, feel free to hit me with > >>> them, and I can try to make heads or tails of them. > >>> > >> How about I do the grunt work and give you a patch instead? > > > > That's always VERY much appreciated. :D > > > > I'd suspected it might end up being a fairly trivial patch, but not > > *that* trivial. I was thinking we might have to deal with split > > outbound buffers similar to the contortions that have to be done for > > receiving, glad to see that's not the case, just some initialization > > differences. Good work! I'll give it a quick test here w/my own gen1 > > transceiver, and will then go ahead and merge it. For good measure, > > Can you add a developer's certificate of origin (Signed-off-by:) line > > for me? Just replying to this email w/it is sufficient. > > Sure: Regarding the patch I sent last night... > Signed-off-by: Patrick Calhoun <ph...@ou...> 2009-08-29 > > I will say that transmitter 2 works as expected, but transmitter 1 > only seems to fire for me when both transmitters are selected, not solo. 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. -- Jarod Wilson ja...@wi... |
From: Calhoun, S. P. <ph...@ou...> - 2009-08-31 05:06:14
|
________________________________________ From: Jarod Wilson [ja...@wi...] Sent: Saturday, August 29, 2009 2:55 PM To: Calhoun, Patrick Cc: lir...@li... Subject: Re: mceusb gen1 transmit >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). 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. 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)? (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.) -Patrick |
From: Jarod W. <ja...@wi...> - 2009-09-02 04:16:27
|
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 much better. > > 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. -- Jarod Wilson ja...@wi... |
From: Jack P. <per...@gm...> - 2009-09-08 01:11:25
|
<snip> (My reply got bounced from the list for my message being too large, so I cut everything above out. My apologies to anybody getting this twice, but I didn't want to remove Jarod or Patrick's private addresses or they may miss future replies. Sorry again) <snip> I've had some trouble here too. I accidentally replied privately to Jarod, so here's a quick transcript: me: ==== It is better, but still no go for me. With cvs post-Jarod's-patch (lirc_mceusb.c version 1.46) my emitter lights up (using transmitter port 2) when told to by irsend, but the cable box seems oblivious to it. I'm using the same remote configuration (SAE8000) that worked for me with a serial blaster, and irw shows that the gen1 is interpreting the cable box remote's transmissions fine so I don't think it's a configuration issue. Please let me know if there's anything I can do to help debug-wise. Jarod: ====== The range of the transmitter is VERY short. If it wasn't just so, the other mceusb transceiver wouldn't pick up squat. It had to be right on the money. Oh, you may also need 'min_repeat 2' added to your transmit remote config bits in lircd.conf. Me: ======= I was pretty much right on top of the sensor so I don't think it's a range thing (that was my first thought too). I'm using the "stock" scientificatlanta/general.conf SAE8000 config... I just checked it and there's no min_repeat in there, so that's definitely something to try. I'll try the min_repeat first and then loop irsend and move the sensor around a bit to see if I get any life. |
From: Jack P. <per...@gm...> - 2009-09-08 01:19:11
|
On Mon, Sep 7, 2009 at 9:11 PM, Jack Perveiler <per...@gm...> wrote: > <snip> > (My reply got bounced from the list for my message being too large, so I > cut everything above out. My apologies to anybody getting this twice, but I > didn't want to remove Jarod or Patrick's private addresses or they may miss > future replies. Sorry again) > <snip> > > > I've had some trouble here too. I accidentally replied privately to Jarod, > so here's a quick transcript: > > me: > ==== > It is better, but still no go for me. With cvs post-Jarod's-patch > (lirc_mceusb.c version 1.46) my emitter lights up (using transmitter port 2) > when told to by irsend, but the cable box seems oblivious to it. I'm using > the same remote configuration (SAE8000) that worked for me with a serial > blaster, and irw shows that the gen1 is interpreting the cable box remote's > transmissions fine so I don't think it's a configuration issue. > > > Please let me know if there's anything I can do to help debug-wise. > > > Jarod: > ====== > The range of the transmitter is VERY short. If it wasn't just so, the other > mceusb transceiver wouldn't pick up squat. It had to be right on the money. > Oh, you may also need 'min_repeat 2' added to your transmit remote config > bits in lircd.conf. > > Me: > ======= > I was pretty much right on top of the sensor so I don't think it's a range > thing (that was my first thought too). I'm using the "stock" > scientificatlanta/general.conf SAE8000 config... I just checked it and > there's no min_repeat in there, so that's definitely something to try. > > I'll try the min_repeat first and then loop irsend and move the sensor > around a bit to see if I get any life. > > <NOTE> This message was also originally bounced for being too large, apologies again to anybody getting it twice Ok, I've had a chance to play with it again. Here are my observations: 1) I ran irsend send_start and moved the transmitter all over the faceplate of my cable box with no hint of any reception. I don't think it's a range/placement issue. 2) I did the same with min_repeat 2 added to my lircd.conf, same results. 3) Thinking that my conf file might not be good (even though it works for irw and lirc_serial), I used irrecord to make a new remote configuration file. It looked largely like the sae8000 one I was using, except it had the min_repeat 2 in there already (ie I didn't have to add it). Using this new config had the same results as prior experiments. 4) I hooked the transmitter up to the receiver (same device) and started looping irsends to it. irw actually did a bang up job of receiving it.. I don't think it dropped anything (ie I didn't see the XOR problem described before). I only ran it for about 30 seconds though, so maybe it would show problems over time. So in the end my configuration seems ok, the device appears to be transmitting, irw likes what it sees, and the only disagreeable party is the cable box. Sounds a lot like Patrick's viera problem. Very odd... irw behaves similarly to my actual remote as it does to the transmission irsend sends. But not the cable box. Just in case I'm a moron, here's my lsusb: Bus 004 Device 002: ID 045e:006d Microsoft Corp. eHome Remote Control Keyboard keys That matches in lirc_mceusb.c as a gen1 device, but when simultaneous transmits/receives worked it got me thinking maybe I'm not gen1 after all. As always, I'm open to ideas and a willing guinea pig for debug experiments :) And sorry about any weird mail threading or formatting problems, I'm still sorting out how to use gmail for mailing list responses. --Jack |
From: Jarod W. <ja...@wi...> - 2009-09-08 13:59:27
|
On 09/07/2009 09:19 PM, Jack Perveiler wrote: > Ok, I've had a chance to play with [$subject] again. Here are my > observations: > > 1) I ran irsend send_start and moved the transmitter all over the > faceplate of my cable box with no hint of any reception. I don't think > it's a range/placement issue. Okay, good to eliminate that as a possibility. > 2) I did the same with min_repeat 2 added to my lircd.conf, same results. Bummer. > 3) Thinking that my conf file might not be good (even though it works > for irw and lirc_serial), I used irrecord to make a new remote > configuration file. It looked largely like the sae8000 one I was using, > except it had the min_repeat 2 in there already (ie I didn't have to add > it). Using this new config had the same results as prior experiments. Might want to post some of the config file for inspection, just in case. A stripped down version with just a few buttons would be sufficient. > 4) I hooked the transmitter up to the receiver (same device) and started > looping irsends to it. irw actually did a bang up job of receiving it.. > I don't think it dropped anything (ie I didn't see the XOR problem > described before). I only ran it for about 30 seconds though, so maybe > it would show problems over time. Reception issues would crop up immediately with mine, but this is when rapidly firing off signals, without any sort of pause in between... Did you have any kind of pause between sends? > So in the end my configuration seems ok, the device appears to be > transmitting, irw likes what it sees, and the only disagreeable party is > the cable box. Sounds a lot like Patrick's viera problem. :\ > Very odd... irw behaves similarly to my actual remote as it does to the > transmission irsend sends. But not the cable box. > > Just in case I'm a moron, here's my lsusb: > > Bus 004 Device 002: ID 045e:006d Microsoft Corp. eHome Remote Control > Keyboard keys > > That matches in lirc_mceusb.c as a gen1 device, but when simultaneous > transmits/receives worked it got me thinking maybe I'm not gen1 after all. Yeah, that's the right device ID. > As always, I'm open to ideas and a willing guinea pig for debug > experiments :) At the moment, I got nothin'. Still need to poke at my own gen1 transceiver a bit more though, so maybe I'll come up with something. -- Jarod Wilson ja...@wi... |
From: <li...@ba...> - 2009-09-08 19:28:50
|
Hi! Jarod Wilson "ja...@wi..." wrote: [...] >> As always, I'm open to ideas and a willing guinea pig for debug >> experiments :) > At the moment, I got nothin'. Still need to poke at my own gen1 > transceiver a bit more though, so maybe I'll come up with something. Does the 1st gen device support changing the transmit carrier frequency? Those SA devices are very picky about that and usually need 56kHz. Christoph |
From: Jarod W. <ja...@wi...> - 2009-09-08 22:54:28
|
On Sep 8, 2009, at 3:22 PM, Christoph Bartelmus wrote: > Does the 1st gen device support changing the transmit carrier > frequency? Hrm. Not sure. Also not sure offhand how to tell... > Those SA devices are very picky about that and usually need 56kHz. -- Jarod Wilson ja...@wi... |
From: Patrick C. <ph...@ou...> - 2009-09-09 21:56:52
|
Jarod Wilson wrote: > On Sep 8, 2009, at 3:22 PM, Christoph Bartelmus wrote: > > >> Does the 1st gen device support changing the transmit carrier >> frequency? >> > > Hrm. Not sure. Also not sure offhand how to tell... > The device certainly acknowledges the freq change requests through the driver. I'm thinking I need to build a small ir detector circuit and pop it onto an oscilloscope to see what's really happening (if anything) to the carrier frequency. I can say that based on the findings reported before, http://article.gmane.org/gmane.comp.hardware.lirc/4982 , the device does purport to support a carrier change. >> Those SA devices are very picky about that and usually need 56kHz. >> |
From: Jarod W. <ja...@wi...> - 2009-09-22 05:23:08
|
On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <ph...@ou...> wrote: > Jarod Wilson wrote: >> On Sep 8, 2009, at 3:22 PM, Christoph Bartelmus wrote: >> >> >>> Does the 1st gen device support changing the transmit carrier >>> frequency? >>> >> >> Hrm. Not sure. Also not sure offhand how to tell... >> > The device certainly acknowledges the freq change requests through > the driver. I'm thinking I need to build a small ir detector circuit > and pop it onto an oscilloscope to see what's really happening (if > anything) to the carrier frequency. > > I can say that based on the findings reported before, > http://article.gmane.org/gmane.comp.hardware.lirc/4982 , > the device does purport to support a carrier change. So I still really haven't dug into this, but yeah, those notes definitely suggest that it should work. That doc also inspired me to poke at the mceusb driver, verifying device bring-up stuff, thinking maybe there was something there to account for xmit only working on port 2. Wasn't really anything, but on a hunch, added the first-gen device to the inverted xmit mask list, and bingo, xmit works on both ports for me. Will commit when I get a chance, don't have great connectivity here where I'm vacationing... (using iphone for this mail) -- Jarod Wilson |
From: Patrick C. <ph...@ou...> - 2009-09-22 14:37:03
|
Jarod Wilson wrote: > On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <ph...@ou...> wrote: >> I can say that based on the findings reported before, >> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , >> the device does purport to support a carrier change. > > So I still really haven't dug into this, but yeah, those notes > definitely suggest that it should work. I have yet to inspect the logs, but I succeeded in controlling my viera tv from a windows app. If there was a carrier change involved, I should be able to identify the command format to do so. > That doc also inspired me to poke at the mceusb driver, verifying > device bring-up stuff, thinking maybe there was something there to > account for xmit only working on port 2. Wasn't really anything, but > on a hunch, added the first-gen device to the inverted xmit mask list, > and bingo, xmit works on both ports for me. > Great news! Your efforts are appreciated! > Will commit when I get a chance, don't have great connectivity here > where I'm vacationing... (using iphone for this mail) So yeah, you make it sound like you brought a laptop and mceusb on your vacation. Don't worry, that's normal. Thanks again, Patrick |
From: Jarod W. <ja...@wi...> - 2009-09-24 04:09:23
|
On Sep 22, 2009, at 10:41 AM, Patrick Calhoun <ph...@ou...> wrote: > Jarod Wilson wrote: >> On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <ph...@ou...> wrote: >>> I can say that based on the findings reported before, >>> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , >>> the device does purport to support a carrier change. >> >> So I still really haven't dug into this, but yeah, those notes >> definitely suggest that it should work. > I have yet to inspect the logs, but I succeeded in controlling my > viera tv from a windows app. If there was a carrier change > involved, I should be able to identify the command format to do so. Pretty sure its covered in that doc already and at a quick glance, I didn't see the driver sending any of the carrier freq change packets... > >> Will commit when I get a chance, don't have great connectivity here >> where I'm vacationing... (using iphone for this mail) > So yeah, you make it sound like you brought a laptop and mceusb on > your vacation. Don't worry, that's normal. Yes, I did bring the laptop and some trinkets to poke at (mceusb transceiver, a usb tv tuner, a video decoder card...), and I know its normal, despite what my wife says. :) -- Jarod Wilson |
From: Jarod W. <ja...@wi...> - 2009-09-27 01:08:33
|
On Thursday 24 September 2009 00:08:26 Jarod Wilson wrote: ... > >>> I can say that based on the findings reported before, > >>> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , > >>> the device does purport to support a carrier change. > >> > >> So I still really haven't dug into this, but yeah, those notes > >> definitely suggest that it should work. > > I have yet to inspect the logs, but I succeeded in controlling my > > viera tv from a windows app. If there was a carrier change > > involved, I should be able to identify the command format to do so. > > Pretty sure its covered in that doc already and at a quick glance, I > didn't see the driver sending any of the carrier freq change packets... I didn't look closely enough. It does send *something*, but I've not walked through all that code to verify its correctness against whats documented. -- Jarod Wilson ja...@wi... |
From: Jack P. <per...@gm...> - 2009-10-15 20:37:20
|
On Sat, Sep 26, 2009 at 8:12 PM, Jarod Wilson <ja...@wi...> wrote: > On Thursday 24 September 2009 00:08:26 Jarod Wilson wrote: > ... > > >>> I can say that based on the findings reported before, > > >>> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , > > >>> the device does purport to support a carrier change. > > >> > > >> So I still really haven't dug into this, but yeah, those notes > > >> definitely suggest that it should work. > > > I have yet to inspect the logs, but I succeeded in controlling my > > > viera tv from a windows app. If there was a carrier change > > > involved, I should be able to identify the command format to do so. > > > > Pretty sure its covered in that doc already and at a quick glance, I > > didn't see the driver sending any of the carrier freq change packets... > > I didn't look closely enough. It does send *something*, but I've not > walked through all that code to verify its correctness against whats > documented. > > -- > Jarod Wilson > ja...@wi... > > > Any more progress on this, or has it fallen squarely into the "boring old driver maintenance" pile? :) I don't mind doing some legwork if it helps, but it sounded like you and Patrick were soooo close a couple weeks ago. Thanks in advance, --Jack |
From: Jarod W. <ja...@wi...> - 2009-10-15 20:42:07
|
On Oct 15, 2009, at 4:37 PM, Jack Perveiler wrote: > On Sat, Sep 26, 2009 at 8:12 PM, Jarod Wilson <ja...@wi...> > wrote: > On Thursday 24 September 2009 00:08:26 Jarod Wilson wrote: > ... > > >>> I can say that based on the findings reported before, > > >>> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , > > >>> the device does purport to support a carrier change. > > >> > > >> So I still really haven't dug into this, but yeah, those notes > > >> definitely suggest that it should work. > > > I have yet to inspect the logs, but I succeeded in controlling my > > > viera tv from a windows app. If there was a carrier change > > > involved, I should be able to identify the command format to do > so. > > > > Pretty sure its covered in that doc already and at a quick glance, I > > didn't see the driver sending any of the carrier freq change > packets... > > I didn't look closely enough. It does send *something*, but I've not > walked through all that code to verify its correctness against whats > documented. > > -- > Jarod Wilson > ja...@wi... > > > > Any more progress on this, or has it fallen squarely into the > "boring old driver maintenance" pile? :) > > I don't mind doing some legwork if it helps, but it sounded like you > and Patrick were soooo close a couple weeks ago. Ah, crap, I actually mostly forgot about this... Doing waaaay too many things at once right now, and while I'm adding this to my official written-down-and-everything TODO list, its not going to make its way to the top in the particularly near future, so anything you can do would be greatly appreciated. -- Jarod Wilson ja...@wi... |
From: Patrick C. <ph...@ou...> - 2009-10-15 22:10:51
|
Jarod Wilson wrote: > On Oct 15, 2009, at 4:37 PM, Jack Perveiler wrote: > > >> >> Any more progress on this, or has it fallen squarely into the >> "boring old driver maintenance" pile? :) >> >> I don't mind doing some legwork if it helps, but it sounded like you >> and Patrick were soooo close a couple weeks ago. >> > > Ah, crap, I actually mostly forgot about this... Doing waaaay too many > things at once right now, and while I'm adding this to my official > written-down-and-everything TODO list, its not going to make its way > to the top in the particularly near future, so anything you can do > would be greatly appreciated. > Ditto that. I haven't given up on the old device, but I can't do much work on this project in the next few weeks. Fingers crossed, I may start in again in December. -Patrick |
From: Jack P. <per...@gm...> - 2009-11-16 16:05:23
|
On Tue, Sep 22, 2009 at 9:41 AM, Patrick Calhoun <ph...@ou...> wrote: > > > Jarod Wilson wrote: > > On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <ph...@ou...> wrote: > >> I can say that based on the findings reported before, > >> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , > >> the device does purport to support a carrier change. > > > > So I still really haven't dug into this, but yeah, those notes > > definitely suggest that it should work. > I have yet to inspect the logs, but I succeeded in controlling my viera > tv from a windows app. If there was a carrier change involved, I should > be able to identify the command format to do so. > > > That doc also inspired me to poke at the mceusb driver, verifying > > device bring-up stuff, thinking maybe there was something there to > > account for xmit only working on port 2. Wasn't really anything, but > > on a hunch, added the first-gen device to the inverted xmit mask list, > > and bingo, xmit works on both ports for me. > > > Great news! Your efforts are appreciated! > > > Will commit when I get a chance, don't have great connectivity here > > where I'm vacationing... (using iphone for this mail) > So yeah, you make it sound like you brought a laptop and mceusb on your > vacation. Don't worry, that's normal. > > Thanks again, > Patrick > > Patrick, Any chance you could post the logs you collected from your successful windows run? I finally have a system set up where I can debug this some. I may be fooling myself wrt how much time I really have due to the holidays coming up but having the logs in hand would at least get me going. Thanks, --Jack |
From: Patrick C. <ph...@ou...> - 2009-11-16 16:25:30
|
Jack Perveiler wrote: > > On Tue, Sep 22, 2009 at 9:41 AM, Patrick Calhoun <ph...@ou... > <mailto:ph...@ou...>> wrote: > > > > Jarod Wilson wrote: > > On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <ph...@ou... > <mailto:ph...@ou...>> wrote: > >> I can say that based on the findings reported before, > >> http://article.gmane.org/gmane.comp.hardware.lirc/4982 , > >> the device does purport to support a carrier change. > > > > So I still really haven't dug into this, but yeah, those notes > > definitely suggest that it should work. > I have yet to inspect the logs, but I succeeded in controlling my > viera > tv from a windows app. If there was a carrier change involved, I > should > be able to identify the command format to do so. > > > That doc also inspired me to poke at the mceusb driver, verifying > > device bring-up stuff, thinking maybe there was something there to > > account for xmit only working on port 2. Wasn't really anything, but > > on a hunch, added the first-gen device to the inverted xmit mask > list, > > and bingo, xmit works on both ports for me. > > > Great news! Your efforts are appreciated! > > > Will commit when I get a chance, don't have great connectivity here > > where I'm vacationing... (using iphone for this mail) > So yeah, you make it sound like you brought a laptop and mceusb on > your > vacation. Don't worry, that's normal. > > Thanks again, > Patrick > > > Patrick, > > Any chance you could post the logs you collected from your successful > windows run? I finally have a system set up where I can debug this > some. I may be fooling myself wrt how much time I really have due to > the holidays coming up but having the logs in hand would at least get > me going. > > Thanks, > > --Jack > I have captured logs in both snoopy pro and in libpcap format. What kind are you looking for? -Patrick |
From: Jack P. <per...@gm...> - 2009-11-16 18:49:55
|
> Patrick, >> >> Any chance you could post the logs you collected from your successful >> windows run? I finally have a system set up where I can debug this some. I >> may be fooling myself wrt how much time I really have due to the holidays >> coming up but having the logs in hand would at least get me going. >> >> Thanks, >> >> --Jack >> >> I have captured logs in both snoopy pro and in libpcap format. What kind > are you looking for? > > -Patrick > Whatever you have, really :) I haven't looked at either format before so I honestly couldn't say which I prefer. This is the first USB-anything I've tried to debug. |