Premise USB-UIRT => Do you have one?

[123]

I'm started writing a native Premise driver for the USB-UIRT and I've made a tiny bit of progress. Please let me know if you use Premise and own a USB-UIRT ... I may call upon you to test the driver.

I've never written a native driver. My less than stellar knowledge of C++ in the context of the Win32PI and ATL COM isn't making it a slam dunk. However, the SDK's documentation, and six-step tutorial for building a driver, have helped me get to the stage where I can detect the presence of the UIRT via its DLL, reads the firmware version, and transmit an IR code.

If you're a C++/Win32API/ATL COM guru:
At the moment, I'm stuck on the UIRT'S callback function.

Whenever the UIRT receives an IR transmission, it invokes its IR Received callback function and it's my driver's responsibility to handle it. I followed the convention used in the UIRT's C++ example but it doesn't work in the driver.

I'm guessing that there may be another way to declare callbacks for ATL (the supplied example shows how to do it for a simple Windows console app) or, and this a wild guess, I'm passing the function's parameters in the wrong order. The UIRT's callback uses the Pascal convention and, even though all the UIRT's functions are explicitly declared that way, it could be that I need to do something else ... something I know nothing about. I got this idea after reading about C++ function pointers and noticed that the UIRT's functions are declared Pascal format.

PS
I'm asking this technical question here because the UIRT's support forum is full of questions and few answers ... similar experience with the support email address.

 

[kzboray]

123,

I don't have the USB-UIRT, but I do use the EZUIRT. Not sure if I can help test for you, but I thought I would mention it just in case. Let me know.

Kaz

 

[123]

Thanks, Kaz. The EZUIRT won't do the trick for me but thanks for letting me know.

 

[123]

I'm pleased to report that a business trip helped to clear my mind and view the code with fresh eyes. I found my error and now Premise can receive IR codes seen by the UIRT. Next step is to add support for the UIRT's Learn mode.

FYI
Gee, you not only have to define the callback function, you ought to register it (with UUIRTSetReceiveCallback) ... duh.

 

[samgreco]

123 - I've been up to my eyeballs with a server migration for a customer and 2 other projects, so have been unable to jump in here. Things should loosen up a bit next week.

For future reference, I do have 2 USB-UIRTs. One on the server and the other on my HTPC. The one on the server is currently being used to change channels on my cable boxes via SageTV. The server is also the Premise server.

So I'd be glad to do some testing for you, as long as it doesn't kill Sage :blink:

 

[123]

I suspect SageTV communicates with the USB-UIRT via the supplied "uuirtdrv.dll" interface. Based on a simple test, I found that one can successfully establish concurrent sessions with the UIRT. That means SageTV and Premise can share the resources of a single UIRT.

The test:
I started two programs (from the USB-UIRT's SDK) and both connected to the UIRT, displayed its firmware revision, and were able to receive IR signals. I couldn't test the case where two IR signals are sent simultaneously (i.e. one from each program). However, aside from it being a rare event, the inability to transmit is an error condition that can be trapped by the driver's code.

 

[Bulkhead]

123, I have a USB-UIRT as well and can test it if you need an additional guinea pig although my programming skills are below beginner.

I am also just coming up to speed on Premise so if you are looking to gauge how ready it is for "dummies" I may be just the person to see if I can get it to work!

cheers,

 

[123]

.. I have a USB-UIRT as well and can test it if you need an additional guinea pig ...

Thank Bulkhead!

I'm trying to ensure my USBUIRT driver complies with the functionality and appearance of existing IR devices supported by Premise like the Global Cache GC-100, the Nirvis Slink-e, and the ADICON SECUIR16. That *should* make it easier to understand and use.

The two attached screenshots show its current appearance. The Main image shows a single instance of a USB-UIRT (I hope to be able to support multiple USB-UIRTs) with its zones represented by Left, Right, Center, and All.

"Left" and "Right" represent the mini-jack on the back of the USBUIRT. "Center" represents the front face of the device and contains both an IR transmitter and receiver. The Center Zone screenshot shows a received IR signal (in Pronto format) in the RxData property and the same signal graphed in the Waveform view.

At the moment the driver does all the ncessary housekeeping for loading/unloading resources, reading the USBUIRT's firmware info and receiving IR commands (in UIR format). The next milestone will be to transmit IR commands followed by learning IR commands (Pronto format). The final detail will be to add a watchdog function so that the driver knows when the USBUIRT is disconnected/re-connected.

 

[123]

Just in case anyone is following my progress ... or plans to write their own USBUIRT driver.

The driver can now learn IR codes in Pronto format (Premise's preferred format). Achieving this goal required jumping through a few more programming hoops:

Use a separate thread for learning.
The USBUIRT's IR learning function works in 'blocking mode' so if you don't run it in a separate thread all UI controls will be ignored until the learning process is completed. That means you can't abort the Learn process and must let it run its course. Putting it in a separate thread circumvents this problem.

Use a delay timer after exiting Learning mode.
Immediately after exiting Learning mode, I've implemented a 4 second delay to suppress the reception of all subsequent IR signals. Here's why:

• In Learning mode, a USBUIRT converts a received IR signal into Pronto format (other formats are also available). In standard operating mode, it converts IR signals into UIR format ... a compressed 'shorthand code' that cannot be used for transmission.
  
• So if you put the USBUIRT in Learning mode and press a button on your remote, it will take about 2-3 seconds to learn the signal and produce a Pronto code ... but then it immediately reverts back to standard operating mode! If you're still holding that remote button down, the learned Pronto code gets overwritten by the incoming UIR code. Not nice. My solution is to ignore incoming IR signals for a few seconds after Learning mode exits normally. Naturally, there's no delay timer activated if you abort the Learning process.

I've tested the driver and it works well with Builder's IR Learning function. Tthe attached image has been annotated to show the steps involved ... point the remote-control at the USBUIRT and follow the steps ... very simple.

 

[123]

After watching the Intelligent IR Control video, I realized that I needed to change a few things so that my driver would work like "Premise intended".

I don't need the delay timer mentioned in the previous post. Based on the video, if you press the Learn icon (an academic "mortarboard"?) to enable Learn mode, the Premise IR driver will stay in this mode until either:

1. you disable it by toggling the Learn icon
2. the inactivity timer expires

The inactivity timer is about five seconds and is not implemented by the driver (it is in Builder)! If Builder doesn't receive a valid Pronto code within 5 seconds of entering Learn mode, it exits Learn mode.

This behavior works better than I imagined because it lets you quickly learn several commands, in one learning session, because Builder automatically steps to the next command in the list (see timemark 41:05 in the video). I thought you had to manually enter and exit Learn mode for each command to be learned! I'm glad that's not how it works!

The next step is to put in a watchdog function that will detect if the USBUIRT is disconnected. Upon disconnection, it will close the existing handle to the device and upon reconnection it will establish a new one. Without this feature, you'd be forced to uninstall/reinstall the entire driver to establish a valid handle.

At the moment, I don't have the C++ skills to make this driver support more than one USB-UIRT device.

 

[project_x]

I'm started writing a native Premise driver for the USB-UIRT and I've made a tiny bit of progress. Please let me know if you use Premise and own a USB-UIRT ... I may call upon you to test the driver.

I've never written a native driver. My less than stellar knowledge of C++ in the context of the Win32PI and ATL COM isn't making it a slam dunk. However, the SDK's documentation, and six-step tutorial for building a driver, have helped me get to the stage where I can detect the presence of the UIRT via its DLL, reads the firmware version, and transmit an IR code.

If you're a C++/Win32API/ATL COM guru:
At the moment, I'm stuck on the UIRT'S callback function.

Whenever the UIRT receives an IR transmission, it invokes its IR Received callback function and it's my driver's responsibility to handle it. I followed the convention used in the UIRT's C++ example but it doesn't work in the driver.

I'm guessing that there may be another way to declare callbacks for ATL (the supplied example shows how to do it for a simple Windows console app) or, and this a wild guess, I'm passing the function's parameters in the wrong order. The UIRT's callback uses the Pascal convention and, even though all the UIRT's functions are explicitly declared that way, it could be that I need to do something else ... something I know nothing about. I got this idea after reading about C++ function pointers and noticed that the UIRT's functions are declared Pascal format.

PS
I'm asking this technical question here because the UIRT's support forum is full of questions and few answers ... similar experience with the support email address.

I've got one and can do a little testing, let me know what you want me to do