Re: mceusb2 documentation

[Jon S. <jon...@gm...>]

On Wed, Sep 24, 2008 at 4:44 PM, Daniel M <li...@ra...> wrote:
> Jon Smirl skrev:
>> Does documentation for mceusb2 devices exist, or has the protocol been
>> reverse engineered?
>>
>>
> Hi Jon,
>
> I have been away from this list for some time now since I have not had
> the time to do any real work on this project for some time.

I posted a new framework integrating LIRC into the input subsystem on LKML.
It's awaiting moderation on this list (1Kb too big).
http://lkml.org/lkml/2008/9/24/328

What do you think about converting the existing MS drivers to work
with this new model?

How does the IR receiver work on there devices? I opened mine up and
it looked like there is a standard 38Khz receiver module and a PIN
diode. Is that a PIN doide? How does 56K reception work?
How about transmitting? how is the 38/56K carrier frequency generated?

> But at the time I worked on this driver I managed to gather some
> information about these devices from various sources and other people on
> this list. And even though no publicly available official documentation
> seems to exist for these devices I'm for instance quite sure that
> lirc_mceusb and lirc_mceusb2 could be merged into one driver.
>
> The biggest difference is that the lirce_mceusb devices needs to have
> its FTDI chip initialized prior to operation. After this the only
> difference is that all command blocks are padded with some extra zeros.
> I even did some code for this but never got hold of any hardware to test
> it on so I never completed it. But if implemented also the 2004 devices
> would get the transmitter capabilities automatically and one driver less
> to maintain.
>
> When it comes to the lirc_mceusb2 devices they do not seem to need any
> initialization (more than maybe a regular usb device reset) and I have
> many times questioned the init codes sent when the device is attached
> since it seems to work just as good without them. I think they exist in
> the Windows driver just to be able to probe the state of the device, but
> we just throw this info away anyway.
> For example the 0xFF 0x0B sequence sent, just responds with the hw/sw
> revision of the device, where a 2004 Microsoft device will respond with
> FF 0B 45 FF 1B 08 and a 2005 Microsoft device responds with FF 0B 50 FF
> 1B 42.
>
> And the new pinnacle init strings added to the driver just means getting
> the carrier (0x07), the blaster bitmask(0x13) and the rx timeout(0x0D).
> Is it verified that these commands are really needed for the device to
> work? Maybe the windows driver have some use for it but lirc does
> nothing with this info.
>
> Also the Lirc API does not support all features possible, like letting
> the mce device detect the carrier frequency of the incoming signal (a
> special learning mode seems to exist). And as mentioned regarding the
> pinnacle init strings you can also probe the device of the current
> status. By the way the default rx time out is set to 100 ms, which also
> explains why this same length of silence is sent when a button is released.
>
> Maybe we can work together in order to get a full understanding of this
> device.
>
> regards
> /Daniel
>



-- 
Jon Smirl
jon...@gm...