Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 32

Thread: Fintek MCEUSB Mythbuntu 12.04.02

  1. #21
    Join Date
    Mar 2008
    Beans
    14

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Have you tried yet? Very excited.

    Quote Originally Posted by billstei View Post
    Around line #461 in mceusb.c there is this definition:

    static char DEVICE_RESUME[] = {MCE_CMD_NULL, MCE_CMD_PORT_SYS,
    MCE_CMD_RESUME};

    which would produce a three byte message: 0x00 0xFF 0xAA

    Again referring to the documentation (see Comment #18 above), page 88 defining the CMD_RESUME, it should be:

    static char DEVICE_RESUME[] = {MCE_CMD_PORT_SYS, MCE_CMD_RESUME};

    which would produce a two byte message: 0xFF 0xAA

    This problem can be seen in my previous dmesg output (Comment #15 above) as:

    92. [10146.244473] mceusb 6-2:1.0: tx data: 00 ff aa (length=3)

    followed by:

    98. [10146.261440] mceusb 6-2:1.0: rx data: 00 ff (length=2)
    99. [10146.261445] mceusb 6-2:1.0: Unknown command 0x00 0xff

    Fixing this makes dmesg a whole lot more exciting, like something started working, but I am not an expert, and I have not tried blasting yet...

  2. #22
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    The number of transmit ports (and receive ports) in the MCEUSB device is determined by issuing the following IR_PORT sub-command:

    CMD_GETIRNUMPORTS (which is 0x16)

    and results in the full command (see pages 94-95 in the documentation):

    0x9F 0x16

    This request goes out every time I reload (rmmod/modprobe) the mceusb module, however I do not always get a response, which is 4 bytes that look like:

    0x9F 0x16 TXC RXC

    where TXC is the number of transmit ports the device has, and RXC is the number of receive ports the device has (see pages 104-105). The problem is that I don't always get a response, for example in my dmesg output (Comment #15, above) the command (request) on line 45 is followed by the response on line 46 (incorrectly reported as 2 bytes, but it was 4), but then the second module unload/load the request goes out on line 109, and is followed by a whole bunch of silence. The key seems to be that on line 106 the device was offended by what was said to it, and shut itself down:

    [10146.292392] mceusb 6-2:1.0: Unknown command 0x9f 0x05

    There is a command going out called "CMD_UNKNOWN2", that is defined in mceusb.c circa line #142 as:

    #define MCE_CMD_UNKNOWN2 0x05 /* Unknown */

    and the full command and sub-command defined circa line#467 as (with line#91 #define MCE_CMD_PORT_IR 0x9f /* IR-related cmd/rsp */ ):

    static char GET_UNKNOWN2[] = {MCE_CMD_PORT_IR, MCE_CMD_UNKNOWN2};

    In other words 0x9f 0x05. This command is sent out circa line #1138 (with comment on #1137) as:

    /* unknown what this one actually returns... */
    mce_async_out(ir, GET_UNKNOWN2, sizeof(GET_UNKNOWN2));

    It is hard to say why all this was done, but if I had to guess, it is either dealing with a "quirk" in certain hardware (in which case it should be the exception to the rule, not the rule), or someone looked at what MS Windows does when it talks to an MCEUSB device, and was trying to duplicate it without knowing why or what it does.

    For all we know it tells the device to switch to 24 Khz, turn off all transmit ports, never talk to anyone ever again, and laugh hysterically about it.

    jk

    I will try removing line #1138 and see what happens. Unfortunately my cable company has also gone biserk and with it the DTA100, so I still can't test the blasting...
    Last edited by billstei; April 12th, 2013 at 10:26 PM.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  3. #23
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    My greatly expanded debug info: dmesg mceusb debug info

    The biggest problem seems to be the NULL bytes ahead of the CMD header that confuse the command parser. The question is whether these NULLs are coming from some USB sub-system code in Linux, or from the MCE USB device. In any event it's a big mess because of it, and a proper workaround would no doubt "fix" it.

    Also for the record the term "cabled" is indeed used to indicate whether an emitter is physically plugged in and can be sensed by the device -- see page 104 of the documentation regarding the VDH byte.

    Edit: Note that I increased the msleep() values from 10 mS to 100 mS to (temporarily) avoid race conditions/problems. The driver runs very slowly this way...
    Last edited by billstei; April 13th, 2013 at 03:55 AM.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  4. #24
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Major bug, circa line #495 in mceusb.c needs:

    case MCE_RSP_GETPORTSTATUS:
    datasize = 5;
    break;

    Should help the parser a bit.

    Edit: Sorry, datasize = 5, not 7.
    Last edited by billstei; April 13th, 2013 at 04:24 AM.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  5. #25
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    I probably won't work on the MCEUSB (and code) much this weekend, but I plan to get back to it on Monday. As far as whether there is any real progress, what I can say is that using the "zero 250 710" DTA100 lirc configuration I can reliably get the emitter LED to flash, including multiple long-term flashes when using the irsend SEND_START directive, and I can now get a frequency value back from the device of 37037 Hz (rather than 24 Khz). Whether that is the correct frequency for the DTA100 is debatable (anyone know? -- if I had a scope I could monitor the official/actual DTA100 Remote output), and the DTA100 does not flash its own LED, so I don't think I have a real "fix" yet. Nevertheless I also want to reduce the changes that I made to mceusb.c down to the essential ones, and generate a patch file so others can easily test with STBs/IR-whatevers and maybe they will have success now that the parser isn't losing its mind and/or the MCEUSB isn't shutting down because the driver is talking trash. I might even throw the "UNKNOWN2" command back in just to see if that makes any difference.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  6. #26
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    This web page: Interpreting Decoded IR Signals lists the XMP protocol at 38 Khz (in other words the Pace DC50X/Motorola DTA100 are sensitive to that frequency, in theory). So the nearest transmitter frequency for the MCEUSB device (pages 88-89) would be 38461 Khz using CP and CC values of 1 and 64. Not too far from 37037 but I also read that XMP is picky (?) so what is "far"?. So in the lirc config file we would add the line:

    frequency 38461

    somewhere before "begin codes" (I put it right after aeps).
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  7. #27
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Looks like there is some work being done by various real actual devs, and this patch and in particular these lines of the patch:

    + { USB_DEVICE(VENDOR_FINTEK, 0x5168),
    + .driver_info = MCE_GEN2_TX_INV },

    determine whether each transmit port is enabled, therefore the Fintek has these enable bits inverted (and shifted? see line #875 in mceusb.c " << 1") and turning them on actually turns them off. Why I am getting flashes on the emitter LED with the port supposedly turned off is a mystery.

    Edit: and this looks even more important:

    This transceiver expects the set IR TX ports and IR data as seperate packets, like the Windows driver does."
    + /* Send the set TX ports command */
    + mce_async_out(ir, cmdbuf, cmdcount);
    + cmdcount = 0;
    +
    Last edited by billstei; April 13th, 2013 at 09:22 PM.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  8. #28
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    All the latest patches from the real devs (like the one above) can be found in mceusb.c in the mainline 3.9-rc6 kernel over at The Kernel Archive, and it compiles OK in Ubuntu 13.04 Beta2+, but I tried blasting with theirs and I still can't talk to the DTA100. Comparing theirs to mine, they have not found some of the bugs I did, so my plan is to merge the two code sets and keep trying.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

  9. #29
    Join Date
    Mar 2008
    Beans
    14

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Any luck after you added your patches?
    Quote Originally Posted by billstei View Post
    All the latest patches from the real devs (like the one above) can be found in mceusb.c in the mainline 3.9-rc6 kernel over at The Kernel Archive, and it compiles OK in Ubuntu 13.04 Beta2+, but I tried blasting with theirs and I still can't talk to the DTA100. Comparing theirs to mine, they have not found some of the bugs I did, so my plan is to merge the two code sets and keep trying.

  10. #30
    Join Date
    Nov 2006
    Beans
    217

    Re: Fintek MCEUSB Mythbuntu 12.04.02

    Still no response from the DTA100, but I can very reliably flash the transmit LED with both SEND_ONCE and SEND_START irsend directives (and do a stop with SEND_STOP). I have every reason to believe that transmitting is working, but either the data sent is corrupt, or the DTA100 has changed since the lirc config file was created (the one by Kirk Bocek). In the mean time I have contacted one of the mceusb.c devs, and he has taught me how to be a real dev, so look for my bug fixes in upcoming (development) kernels, probably 3.9-ish. I can also verify that the "frequency" option in the lirc config file (for example dta100.conf) will have no effect as the mceusb module code currently stands, but that is another fix/patch I plan to submit.
    CPU: 80286 @ 10Mhz; FPU: n/a; RAM: 256K, HD: 20 Meg
    Graphics: Monochrome; Power Supply: 100 W; Case: Yes/Open

Page 3 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •