[mythtv-users] HDPVR IR blaster slow

[Mike Perkins]

On 20/06/15 21:39, Joseph Fry wrote:
>>
>>>>> I know that i2c_master_send can handle up to 64k... so I think I may
>> try
>>>>> and
>>>>> force it to send everything in one go rather than breaking it up.  I
>>>>> doubt
>>>>> it will work, but it would be interesting if it did.
>>
>> i2c_master_send() does indeed have that 64K limit, but many actual I2C
>> master hardware implementations can't support anywhere near that.
>> It's not uncommon for them to have length limits on the order of 16 or
>> 64.  In other words, don't assume that just because the Linux
>> framework supports sending messages up to that size that the hardware
>> itself can support it.
>>
>>>>> Beyond that, I can't see anything else to do to make this faster.
>>>>
>>>> You will likely have to look at the IC datasheets, HD-PVR schematics,
>>>> and HD-PVR firmware (only the first is likely publicly available) to
>> know
>>>> what can be sent across the i2c bus.  It can be fun experimenting and
>>>> reverse engineering, but it may not be successful.
>>
>> Bear in mind that the Windows driver implementation for the ZIlog was
>> originally written for the much older PVR-x50 cards (which is what got
>> copied through reverse engineering into the Linux implementation).
>> Hence it's likely that I2C masters in newer hardware designs such as
>> the HDPVR don't have the 4-byte limit - but bear in mind that if you
>> change the driver than it will likely be rejected upstream since it
>> would break interaction with older products that use the same driver.
>>
>>>> At some point, it is likely going to be worth your time to simply
>> purchase
>>>> another transmitter (but you probably already knew that).
>>>>
>>>> Good luck.
>>>
>>>
>>> Believe it or not... it works fine passing all 400 bytes at once.  Shaved
>>> the time for 10 key presses from over 10 seconds to under 9 seconds...
>> sigh.
>>
>> Correct, the I2C master on the Ambarella doesn't have the 4-byte
>> limit.  I have an implementation which I've used in house which puts
>> the whole blob out in a single transaction.
>>
>> The bulk of the time won't be clocking out the bytes for the
>> particular RC code.  It's the last I2C message which says "go" once
>> the RC blob is fully loaded which is going to block until the code is
>> fully transmitted (and RC codes themselves can have a delay at the end
>> after clocking out the last pulse).  Also bear in mind that how long
>> it takes can vary based on the particular RC codeset and protocol that
>> your particular STB requires.  Hence it's entirely likely that other
>> people may say that it works much faster if they're talking to a STB
>> that doesn't require as much delay between keys.
>>
>> Just as a test, you may wish to fire the HDPVR up under Windows and
>> see if it exhibits the same behavior.  That will tell you definitively
>> if the Linux driver is doing something that is outright dumb (i.e. not
>> properly emulating the Windows behavior), or it it might just be a
>> limitation of the particular RC codeset required for your STB.
>>
>
> Well... testing in windows does seem to indicate that it's an issue with
> the codeset as it's every bit as slow there as in linux.
>
> I guess I will just have to accept it as is for now, until I can find
> something better.
>
> Speaking of better, I know the MCEUSB devices are the best supported, but I
> can't seem to find anything that has multiple transmitters.  I know I had
> an old ehome unit that had two emmitter ports, but I am not sure they were
> independently addressable.
>
> I would welcome suggestions of a working solution for 4 emitters that is
> dirt cheap and easily implemented (would rather not have to compile drivers
> for each one and whatnot).
>
> Thanks everyone for your input on this... it's been fun getting into the
> code.
>
Try the Iguana USB transmitter/receiver units. They can drive up to four 
blasters from a single unit. The minor downside is that they need their own 
driver but that is available and LIRC-compatible.

-- 

Mike Perkins