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 |