Sharp send timing

--===============8055086659431165937==
Content-Type: multipart/alternative; boundary="000000000000a3df290606398f53"

--000000000000a3df290606398f53
Content-Type: text/plain; charset="UTF-8"

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.

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.

What am I missing?

--000000000000a3df290606398f53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>The Sharp remote send timing appears to be off f=
rom what I can track down. I started investigating this because my Denon re=
ceiver I&#39;m trying to send commands to appears to be more sensitive to I=
R command timing and doesn&#39;t always response where as my other devices =
appear to work just fine using LIRC.</div><div><br></div></div>According to=
 this page=C2=A0<a href=3D"https://www.sbprojects.net/knowledge/ir/sharp.ph=
p">https://www.sbprojects.net/knowledge/ir/sharp.php</a> a logical &quot;1&=
quot; should be 2ms in total length and &quot;0&quot; should be 1ms in tota=
l length. If I use ir-ctl to measure the raw values from my remote I can co=
nfirm this timing (also confirmed using my ocilloscope). If I try to transm=
it using this command &quot;ir-ctl -d /dev/lirc0 -S sharp:0x2e1&quot; and v=
iew the results on my oscilloscope=C2=A0I&#39;m seeing 2.3ms and 1.3ms inst=
ead of the expected 2ms and 1ms. Not 100% sure where this code is hiding bu=
t I found a couple places on github that relate to this timing issue...<div=
><br></div><div>This is the code I found in the Linux kernel</div><div><a h=
ref=3D"https://github.com/torvalds/linux/blob/master/drivers/media/rc/ir-sh=
arp-decoder.c#L17-L18">https://github.com/torvalds/linux/blob/master/driver=
s/media/rc/ir-sharp-decoder.c#L17-L18</a><br></div><div>sharp_unit =3D 40<b=
r></div><div>40 * 8 =3D 320 for the pulse is correct. But then the space is=
 either 40 * 50 =3D 2,000 or 40 * 25 =3D 1,000=C2=A0 which I believe=C2=A0s=
hould be 40 * (50-8) =3D 1,680 and 40 * (25-8) =3D 680 to account for the i=
nitial bit pulse.</div><div><br></div><div>This is the code I could find fo=
r ir-ctl...</div><div><a href=3D"https://github.com/cz172638/v4l-utils/blob=
/master/utils/ir-ctl/ir-encode.c#L149-L151">https://github.com/cz172638/v4l=
-utils/blob/master/utils/ir-ctl/ir-encode.c#L149-L151</a><br></div><div>It =
has a similar problem, it doesn&#39;t appear to be taking into account the =
initial bit pulse into the timing.<br></div><div><br></div><div>What am I m=
issing?</div><div><br></div></div>

--000000000000a3df290606398f53--


--===============8055086659431165937==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============8055086659431165937==--