Re: Sharp send timing

On Mon, Sep 25, 2023 at 10:08:59PM -0400, Joe Ferner wrote:
> The Sharp remote send timing appears to be off from what I can track down.
> I started investigating this because my Denon receiver I'm trying to send
> commands to appears to be more sensitive to IR command timing and doesn't
> always response where as my other devices appear to work just fine using
> LIRC.
> 
> According to this page https://www.sbprojects.net/knowledge/ir/sharp.php a
> logical "1" should be 2ms in total length and "0" should be 1ms in total
> length. If I use ir-ctl to measure the raw values from my remote I can
> confirm this timing (also confirmed using my ocilloscope). If I try to
> transmit using this command "ir-ctl -d /dev/lirc0 -S sharp:0x2e1" and view
> the results on my oscilloscope I'm seeing 2.3ms and 1.3ms instead of the
> expected 2ms and 1ms. Not 100% sure where this code is hiding but I found a
> couple places on github that relate to this timing issue...
> 
> This is the code I found in the Linux kernel
> https://github.com/torvalds/linux/blob/master/drivers/media/rc/ir-sharp-decoder.c#L17-L18
> sharp_unit = 40
> 40 * 8 = 320 for the pulse is correct. But then the space is either 40 * 50
> = 2,000 or 40 * 25 = 1,000  which I believe should be 40 * (50-8) = 1,680
> and 40 * (25-8) = 680 to account for the initial bit pulse.

You're right, there is a problem here. 

I've submitted a patch:

https://patchwork.linuxtv.org/project/linux-media/patch/[email protected]/

> This is the code I could find for ir-ctl...
> https://github.com/cz172638/v4l-utils/blob/master/utils/ir-ctl/ir-encode.c#L149-L151
> It has a similar problem, it doesn't appear to be taking into account the
> initial bit pulse into the timing.

Looks like it has exactly the same problem, am I mistaken?

I'll write a patch for ir-ctl too.

Thanks for reporting.

Sean