mceusb gen1 transmit

[Patrick Calhoun]

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

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
jarod@...




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Patrick Calhoun]

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

diff -u -8 -p -r1.44 lirc_mceusb.c
--- drivers/lirc_mceusb/lirc_mceusb.c 2 Aug 2009 11:15:28 -0000 1.44
+++ drivers/lirc_mceusb/lirc_mceusb.c 28 Aug 2009 23:54:34 -0000
@@ -11,16 +11,19 @@
  *
  * Original lirc_mceusb driver deprecated in favor of this driver, which
  * supports the 1st-gen device now too. Transmitting on the 1st-gen device
  * is as yet untested, but receiving definitely works.
  *
  * Support for 1st-gen mceusb device added in June of 2009,
  * by Jarod Wilson <jarod@...>
  *
+ * Transmission support for 1st-gen mceusb device added in August of 2009,
+ * by Patrick Calhoun <phineas@...>
+ *
  * Derived from ATI USB driver by Paul Miller and the original
  * MCE USB driver by Dan Conti ((and now including chunks of the latter
  * relevant to the 1st-gen device initialization)
  *
  * This driver will only work reliably with kernel version 2.6.10
  * or higher, probably because of differences in USB device enumeration
  * in the kernel code. Device initialization fails most of the time
  * with earlier kernel versions.
@@ -887,30 +890,42 @@ static int mceusb_gen1_init(struct mceus
 
  /*
  * This is a strange one. They issue a set address to the device
  * on the receive control pipe and expect a certain value pair back
  */
  memset(data, 0, 8);
 
  ret = usb_control_msg(ir->usbdev, usb_rcvctrlpipe(ir->usbdev, 0),
-      5, USB_TYPE_VENDOR, 0, 0,
+      USB_REQ_SET_ADDRESS, USB_TYPE_VENDOR, 0, 0,
       data, 2, HZ * 3);
  dprintk("%s - ret = %d, devnum = %d\n",
  __func__, ret, ir->usbdev->devnum);
  dprintk("%s - data[0] = %d, data[1] = %d\n",
  __func__, data[0], data[1]);
 
  /* set feature */
  ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
       USB_REQ_SET_FEATURE, USB_TYPE_VENDOR,
       0xc04e, 0x0000, NULL, 0, HZ * 3);
-
  dprintk("%s - ret = %d\n", __func__, ret);
 
+ /* strange: bRequest == 4 */
+        ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
+                              4, USB_TYPE_VENDOR,
+                              0x0808, 0x0000, NULL, 0, HZ * 3);
+ dprintk("%s - retB = %d\n", __func__, ret);
+
+ /*  strange: bRequest == 2 */
+        ret = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
+                              2, USB_TYPE_VENDOR,
+                              0x0000, 0x0100, NULL, 0, HZ * 3);
+ dprintk("%s - retC = %d\n", __func__, ret);
+
+
  return ret;
 
 };
 
 static int mceusb_dev_probe(struct usb_interface *intf,
  const struct usb_device_id *id)
 {
  struct usb_device *dev = interface_to_usbdev(intf);
@@ -1162,18 +1177,20 @@ mem_failure_switch:
  if (ir->flags.microsoft_gen1)
  mceusb_gen1_init(ir);
 
  request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  request_packet_async(ir, ep_out, init1,
      sizeof(init1), MCEUSB_OUTBOUND);
  request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
- request_packet_async(ir, ep_out, init2,
-     sizeof(init2), MCEUSB_OUTBOUND);
+ /* This request packet breaks transmission for gen1 */
+ if (! ir->flags.microsoft_gen1)
+ request_packet_async(ir, ep_out, init2,
+     sizeof(init2), MCEUSB_OUTBOUND);
  request_packet_async(ir, ep_in, NULL, maxp, 0);
  }
 
  usb_set_intfdata(intf, ir);
 
  return 0;
 }
 

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

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
jarod@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

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
jarod@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Patrick Calhoun]

On Aug 28, 2009, at 10:17 PM, "Jarod Wilson" <jarod@...> 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 <phineas@...> 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
> jarod@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

On Saturday 29 August 2009 15:20:54 Calhoun, Sean P. wrote:

>
> On Aug 28, 2009, at 10:17 PM, "Jarod Wilson" <jarod@...> 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 <phineas@...> 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
jarod@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Patrick Calhoun]

________________________________________
From: Jarod Wilson [jarod@...]
Sent: Saturday, August 29, 2009 2:55 PM
To: Calhoun, Patrick
Cc: lirc-list@...
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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

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
jarod@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jack Perveiler-2]

<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.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jack Perveiler-2]

On Mon, Sep 7, 2009 at 9:11 PM, Jack Perveiler <perveilerj@...> 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


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

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
jarod@...

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Christoph Bartelmus]

Hi!

Jarod Wilson "jarod@..." 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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

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
jarod@...




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Patrick Calhoun]

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.
>>    

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

[Jarod Wilson]

On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <phineas@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf

[Patrick Calhoun]

Jarod Wilson wrote:
> On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <phineas@...> 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


------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf

[Jarod Wilson]

On Sep 22, 2009, at 10:41 AM, Patrick Calhoun <phineas@...> wrote:

> Jarod Wilson wrote:
>> On Sep 9, 2009, at 6:00 PM, Patrick Calhoun <phineas@...> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf

[Jarod Wilson]

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
jarod@...

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf

[Jack Perveiler-2]

On Sat, Sep 26, 2009 at 8:12 PM, Jarod Wilson <jarod@...> 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
jarod@...

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

------------------------------------------------------------------------------
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