Firmware v5.9 with Linux kernel v2.6.8

[chrisb]

I have been trying unsuccessfully for the last two weeks to get my USB-UIRT to work with my Misterhouse system which runs on FC2. The UU works fine with Girder and CQC on my Windows XP box so I'm confident that it's not an issue with the UU.

I was able to train CQC with my VCR remote and successfully play back the learnt commands. The added bonus is that I was able to export the learnt commands out to an XML file and this file contains the Pronto codes as shown below:

<?xml version='1.0' encoding='UTF-8'?>
<CQCIR:ExportFile CQCIR:Blaster='USB-UIRT'
CQCIR:Make='Panasonic'
CQCIR:Model='NV-SD420'
CQCIR:RepeatCount='2'
CQCIR:Description='VCR'
CQCIR:Category='VCR'
xmlns:CQCIR='http://www.charmedquark.com/IRExport'>
<CQCIR:Commands>
<CQCIR:Cmd CQCIR:CmdName='CH-'
CQCIR:Data='0000 0070 0000 0032 0082 0041 0011 0010 0011
0031 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010
0011 0010 0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011
0010 0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011 0031
0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011
0010 0011 0031 0011 0010 0011 0031 0011 0010 0011 0031 0011 0031 0011 0010
0011 0010 0011 0031 0011 0010 0011 0031 0011 0010 0011 0010 0011 0031 0011
0010 0011 0031 0011 0AD1'/>
<CQCIR:Cmd CQCIR:CmdName='CH+'
CQCIR:Data='0000 006F 0000 0032 0083 0041 0011 0010 0011
0031 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010
0011 0010 0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011
0010 0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011 0031
0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011
0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0031 0011 0031 0011 0010
0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011 0031 0011
0010 0011 0031 0011 0ADC'/>
</CQCIR:Commands>
</CQCIR:ExportFile>

My interpretation of the Pronto data for CH+ is as follows:

0000
006f (Frequency = 37.343kHz)
0000 (Code1 = 0 pairs)
0032 (Code2 = 50 pairs)
0083 0041 (Lead In Burst)
0011 0010 0011 0031 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010
0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010
0011 0010 0011 0010 0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011 0031
0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010
0011 0010 0011 0010 0011 0031 0011 0010 0011 0031 0011 0031 0011 0010 0011 0010
0011 0010 0011 0010 0011 0031 0011 0010 0011 0010 0011 0031 0011 0010 0011 0031
0011 0adc (Lead Out Burst = 2780 => 0.0744 seconds)

I proceeded to cut and paste the Pronto codes into MH and supplied a repeat count of 2 as per the above config file. Sending the command via the usb_uirt_update web interface of MH turned on the LED lights but I got no response from the VCR.

When I send CH+ I see that the following sequence (with my interpretations) is being sent by MH to the UU:

36 (Cmd = DOTXRAW)
6a (CmdLength = 106 bytes)
43 (Frequency = 37.313kHz)
04 (Repeat Count = 4) [This was 2 but I increased it to 4 with no effect]
0573 (Interspace Delay = 1395 => 1395 * 50E-6 = 0.06975 seconds)
64 (Raw Byte Count = 100 :: 80,83,...,31,11 = 100 bytes)
8083 41
11 10 11 31 11 10 11 10 11 10 11 10 11 10 11 10
11 10 11 10 11 10 11 10 11 10 11 31 11 10 11 10
11 10 11 10 11 10 11 10 11 31 11 10 11 10 11 31
11 10 11 10 11 10 11 10 11 10 11 10 11 10 11 10
11 10 11 10 11 31 11 10 11 31 11 31 11 10 11 10
11 10 11 10 11 31 11 10 11 10 11 31 11 10 11 31
11
6e (Checksum ) [I haven't manually calculated this but the checksum seems to work ok for the "simple" commands]

The data stream being sent to the USB-UIRT looks fine to me and I don't get an error code. I'm wondering if something has been changed in the firmware and the Windows apps are working because they use Jon's DLL but MH isn't because it's sending the commands directly to the UU.

I've also applied the LIRC patches provided in the the Developers Forum and was unable to get those to work either. My suspicion is that there's some sort of problem with the 2.6.8 kernel and/or firmware v5.9

Is anyone successfully using a USB-UIRT with:
- firmware v5.9 on a 2.6.8 kernel?
- any firmware version with a 2.6.8 kernel?
- firmware v5.9 on another version of the kernel?

Any other ideas (eg things to test) would be appreciated?

[jrhees]

Do you have the ability to alter what MH sends?

I ran your code through the DLL and this is what gets sent to the USB-UIRT:

36 (Cmd = DOTXRAW)
6c (CmdLength = 108 bytes)
42 (Frequency = ..
04 (Repeat Count = 4)
0000 (Interspace Delay = 0)
66 (Raw Byte Count = 100 :: 80,83,...,31,11 = 100 bytes)
8083 41
11 10 11 31 11 10 11 10 11 10 11 10 11 10 11 10
11 10 11 10 11 10 11 10 11 10 11 31 11 10 11 10
11 10 11 10 11 10 11 10 11 31 11 10 11 10 11 31
11 10 11 10 11 10 11 10 11 10 11 10 11 10 11 10
11 10 11 10 11 31 11 10 11 31 11 31 11 10 11 10
11 10 11 10 11 31 11 10 11 10 11 31 11 10 11 31
11
8adc (Interspace delay)
77 (checksum)

The notable differences here is that my version actually 'cheats' versus the spec, by encoding the inter-space delay as a trailing space (like a Pronto code does). The firmware can accomodate this. The other difference is the IR frequency, which is different due to how rounding works in the API driver.

If you *can* experiment with this, it would be interesting to know if the IR frequency or the ISdelay is causing the issue here. Hopefully the ISdelay isn't the issue, since these should be roughly equivalent (although the ISdelay actual delay time might be a bit different).

-Jon

[judapeno]

The main difference I see is that you are no longer using the interspace delay field as defined in the protocol spec and instead adding a long space at the end of the data.

Chris, I can make this change to the Misterhouse code or you can. Let me know.

David

[jrhees]

Please let me know what you find! If moving the ISdelay make the code start working, I want to know about it (since they should be pretty equivalent other than minor timing shifts)

Thanks,

-Jon