Structure packing

Interested in integrating USB-UIRT support into an application? Look here!

Moderator: jrhees

Postby jrhees » Wed Sep 17, 2003 3:38 am

Perhaps the way to think about this is the same way equipment does. For equipment that uses a remote which continuously sends out codes for the duration of the button press, equipment may respond in one of two ways:

1. Some equipment will begin a 'repeat' sequence (similar to holding down a key on a computer keyboard).

2. Other equipment will debounce the button press, and not consider a 'new' button press until a period of inactivity has occurred (similar to the timing scheme you're putting in).

Now, for completeness, other equipment deals with this issue in an entirely other way:

- Some equipment sends a single burst out of the remote for each button press. However, this is the *exception*, not the rule, since it is deemed more frustrating to a user if equipment doesn't respond when a button is pressed simply because the user's remote is still in motion (is being brought up from the couch when the button press begins).

- Other equipment uses the RC-5 protocol, which toggles between two different codes between each button-press.

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Dean Roddey » Wed Sep 17, 2003 6:00 am

Ok, something is definitely wrong here. I was testing my learning code and it wasn't working. I messed around and messed around and it's not doing anything. Receiving is working fine, but as soon as I enter the training call, it doesn't respond and the LED doesn't blink when I press buttons. If I set the cancel flag it pops right back out, so it's not totally confused, and after it pops out, receiving still works.

I finally got smart and tried your trydrv.exe program, and it is acting the exact same way, so it's obviously not me. Both of us show 5.4, 1.1, 4/30/2003, and I loaded the drivers from the 1.2 driver zip file. the uuirtdrv.dll is 86016 bytes and shows 5/02/2003 as the date.

I've unplugged the device and plugged it back in a couple times just to make sure that it's reset. So I'm kind of stuck here on this one.
Dean Roddey
 

Postby Dean Roddey » Wed Sep 17, 2003 6:59 am

I tried it on another machine, completely different type, just to be sure, and I'm getting the exact same results. It won't learn in any format, but it will receieve and let me set config bits and such, and your trydrv program has the same problem. I'm using the trydrv as it was shipped, so it was as built by you.

I thought at first that maybe you driver might have some issue on my dual CPU development system, but the other machine is a single CPU laptop. Both are running XP with the latest patches and SPs.
Dean Roddey
 

Postby jrhees » Wed Sep 17, 2003 3:24 pm

Dean,

Most likely the problem you're experiencing is that it isn't clearly documented (outside of Girder) how learning takes place.

When learning, a completely different IR sensor is used in the USB-UIRT. It is a special wideband sensor, which for noise rejection reasons, as well as to detect frequencies and to record the IR data on an exact waveform basis, is a very short-range sensor. This sensor is similar to that of sensors used on 'learning' remote controls.

So... when Learning an IR stream for retransmission, it is necessary to hold the remote between 2 and 6 inches away from the USB-UIRT and to point the remote directly at the face of the USB-UIRT, just to the left of the RED LED. For best results, it is advised to have both laying on a flat surface to avoid movement during the learn process.

Since remote controls vary in strength, the optimum distance varies from remote to remote. When at a good distance, the LED will blink continuously. Also, the 'Signal Quality' value in the Learn callback will help you to determine if distance is good.

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Dean Roddey » Wed Sep 17, 2003 6:52 pm

Ok, yes that was it. Whew... I thought it was something really wierd. Thanks.
Dean Roddey
 

Postby Dean Roddey » Wed Sep 17, 2003 9:06 pm

Here is a version of the header I did for my own needs. It's in terms of my CIDLib C++ Frameworks types, but they should be obvious. It uses the kinds of stuff that are needed and/or desirable for a C++ client app. The WNDPROCAPI define is one of mine also, which comes from a per-platform define, and in this case is just __stdcall.

Code: Select all
extern "C"
{
    // A small structure that the UUIRT returns
    struct TUIRTInfo
    {
        tCIDLib::TCard4 c4FWVersion;
        tCIDLib::TCard4 c4ProtVersion;
        tCIDLib::TCard1 c1Day;
        tCIDLib::TCard1 c1Month;
        tCIDLib::TCard1 c1Year;
    };


    // A handle for the UUIRT
    typedef tCIDLib::TVoid** TUUHandle;


    // Prototypes for some callbacks the UUIRT makes to us
    typedef tCIDLib::TVoid (WNDPROCAPI* TCallbackProc)
    (
        const   tCIDLib::TSCh* const    pszIREventStr
        ,       tCIDLib::TVoid* const   pUserData
    );

    typedef tCIDLib::TVoid (WNDPROCAPI* TLearnCallbackProc)
    (
        const   tCIDLib::TCard4         c4Progress
        , const tCIDLib::TCard4         c4SigQuality
        , const tCIDLib::TCard4         c4CarrierFreq
        ,       tCIDLib::TVoid* const   c4UserData
    );


    //
    //  Typedefs for the APIs that we load up dynamically to get function
    //  pointers that we can call.
    //
    typedef TUUHandle (WNDPROCAPI* TUUIRTOpen)();

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTClose)
    (
                TUUHandle               hHandle
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTGetDrvInfo)
    (
                tCIDLib::TCard4* const  pc4DrvVersion
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTGetUUIRTInfo)
    (
                TUUHandle               hHandle
        ,       TUIRTInfo* const        pInfo
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTGetUUIRTConfig)
    (
                TUUHandle               hHandle
        ,       tCIDLib::TCard4* const  pc4Config
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTSetUUIRTConfig)
    (
                TUUHandle               hHandle
        , const tCIDLib::TCard4         c4Config
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTSetRecCB)
    (
                TUUHandle               hHandle
        ,       TCallbackProc           pfnReceiveProc
        ,       tCIDLib::TVoid* const   pUserData
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTTransmitIR)
    (
                TUUHandle               hHandle
        , const tCIDLib::TSCh* const    pszIRCode
        , const tCIDLib::TInt4          i4CodeFormat
        , const tCIDLib::TInt4          i4RepeatCount
        , const tCIDLib::TInt4          i4InactivityWaitTime
        ,       tCIDLib::TVoid* const   hEvent
        , const tCIDLib::TVoid* const   pReserved0
        , const tCIDLib::TVoid* const   pReserved1
    );

    typedef tCIDLib::TSInt (WNDPROCAPI* TUUIRTLearnIR)
    (
                TUUHandle               hHandle
        , const tCIDLib::TCard4         c4CodeFormat
        ,       tCIDLib::TSCh* const    pszIRCode
        ,       TLearnCallbackProc      pfnProgressProc
        ,       tCIDLib::TVoid* const   pUserData
        ,       tCIDLib::TCard4* const  pc4Abort
        , const tCIDLib::TCard4         c4Param1
        , const tCIDLib::TVoid* const   pReserved0
        , const tCIDLib::TVoid* const   pReserved1
    );
}


//
//  UUIRT related constants
//
namespace kUSBUIRT
{
    const tCIDLib::TCard4   c4Cfg_LEDRX         = 0x0001;
    const tCIDLib::TCard4   c4Cfg_LEDTX         = 0x0002;
    const tCIDLib::TCard4   c4Cfg_LegacyRX      = 0x0004;

    const tCIDLib::TCard4   c4IRFmt_UUIRT       = 0x0000;
    const tCIDLib::TCard4   c4IRFmt_Pronto      = 0x0010;

    const tCIDLib::TCard4   c4Learn_ForceRaw    = 0x0100;
    const tCIDLib::TCard4   c4Learn_ForceStruc  = 0x0200;
    const tCIDLib::TCard4   c4Learn_ForceFreq   = 0x0400;
    const tCIDLib::TCard4   c4Learn_FreqDetect  = 0x0800;

    const tCIDLib::TCard4   c4Err_NoDevice      = 0x20000001;
    const tCIDLib::TCard4   c4Err_NoResp        = 0x20000002;
    const tCIDLib::TCard4   c4Err_NoDLL         = 0x20000003;
    const tCIDLib::TCard4   c4Err_Version       = 0x20000004;

    const tCIDLib::TVoid* const hInvalid        = (tCIDLib::TVoid*)kCIDLib::c4MaxCard;
}
Dean Roddey
 

CQC USB-UIRT driver is now available

Postby Dean Roddey » Thu Oct 09, 2003 7:26 am

I just made the 0.9.2 release of CQC available, which now includes the USB-UIRT driver. It all seems to be working happy tunes, so I'm glad to get this support for the UIRT into CQC (and it had been being requested a good bit.) Thanks to Jon for helping me out with issues.
Dean Roddey
 

Oh and....

Postby Dean Roddey » Thu Oct 09, 2003 7:28 am

I guess I should have provided the URL, in case anyone is interested. It's at http://www.charmedquark.com
Dean Roddey
 

Postby jrhees » Thu Oct 09, 2003 1:40 pm

Dean,

Thanks for the support (and all of the suggestions, too!).

Please, when you get time, send me a logo I can use for a website link.

Best Regards,

Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Dean Roddey » Sun Oct 12, 2003 8:44 pm

You can just swipe the logo off the web site. It's at the top of each page.
Dean Roddey
 

Postby jrhees » Mon Oct 13, 2003 1:44 am

Thanks! I'll get on it soon!

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Previous

Return to Developers

Who is online

Users browsing this forum: No registered users and 31 guests