#275 ftdi driver gives incorrect pulse timings.

[John Penfold]

System info: Debian GNU/Linux 9.0 (Stretch), with lirc version 0.9.4c-7 and libftdi version 1.3-2+b2

When using a USB infra-red receiver based on ftdi's FT230X chip with the ftdi driver and a pre-defined handset *.conf file there are pulse timings displayed by mode2 but no decoded output from irw. Investigation revealed that LIRC could not find a remote control config with timings that matched the received signal.

Comparison between the mode2 outputs from the ftdi receiver and a system using a serial port receiver showed that the ftdi receiver pulses were twice the width.
To check sending, an oscilloscope was used to monitor the transmit output pin, the pulses were half the width they should have been. The ftdix driver (send only) produces the correct output.

Looking through the code in ftdi.c i found in parsesamples() the following
/ Convert number of samples to us.

* The datasheet indicates that the sample rate in
* bitbang mode is 16 times the baud rate but 32 seems
* to be correct. */
usecs = (rxctr * 1000000LL) / (rx_baud_rate * 32);
I did some experiments and found that it was actually 64 * the baudrate. This is due to a poorly documented "feature" of ftdi_set_baudrate() in libftdi, if the chip is in bitbang mode the supplied baudrate is multiplied by 4 before setting the chip.
The baudrate multiplier in the parsesamples() needs to be 64 instead of 32, which will halve the time measured, correcting the output. To correct the sending side, the multiplier of tx_baud_rate in hwftdi_send() needs to change from 8 to 16, which will correct the pulsewidths.

If the config file for the handset is created using irrecord, then the remote will work, as the timings match the config data. When the bug is fixed these will stop working as the received pulses no longer match the config data. The fix should include an option for a 'compatability' mode to use the original behaviour.

[Alec Leamas]

Thanks for patch sent by private email. I attach it here, together with a tentative add-on patch. Notes on the combined thing:

• The patch does not apply to the master branch. This is a blocking error. The rejected hunk could be found in the 0001- commit message.
• We should not abuse the device path with the new 'old-timing' option - this is better handled using the new driver option feature. This is fixed in 0002-
• We neeed to update driver docs on this, in particular how to adjust existing lircd.conf files timings to the new, correct behaviour in the ftdi driver.
• Testiing needs to be done using the master branch

If you could fix these notes I would be really happy to apply this patch. Please let me know if you need help to run the master version, or if there is any other troubles!

[John Penfold]

I have now got the patch to apply to the master branch and have incorporated the 0002-Add-fixws.patch. I have also included information for updating the lircd.conf file in the documentation.

I found during testing that there is no entry for driver-options in the lirc_options.conf file, also driver options cannot be applied to irrecord.

[Bengt Martensson]

I would strongly advise against supporting old "off-by-a-factor-2" configuration files.

Lirc configuration files (strictly speaking "with timing information") describe a number of IR commands. The are not bound to a particular driver. (Lirccode drivers are different, but that is beside the point.) So, supporting off-by-factor-2 has to work for all drivers....

[Alec Leamas]

Thanks for updated patch, committed as [328f51].

I found during testing that there is no entry for driver-options in the lirc_options.conf file

lirc_options.conf actually does support driver options; however, a documentation comment in the template was missing. This is fixed here.

also driver options cannot be applied to irrecord.

Nice catch! Filed as [#277]

Once again: Many thanks for hunting this down and providing a patch!

@bengt: I think we need the off-by-a-factor-2 support as a transition feature to help users with existing files. I have updated the docs so that it's clear that this support will be removed in a later release.

[Guy Delamarter]

I am running lirc 0.10.0 (0.10.0-6.fc27) libftdi-1.3-7.fc27 with this patch. I am using an ftdi transmitter (FT232RL) on lircd. (Intel x86 system, Fedora 27).

My configuration file says:

one 300 850
zero 300 280

Are those pulse space numbers supposed to be in microseconds? The docs seem to say they are...

What should I expect mode2 (on an independent receiver) show for the raw receive for a one and a zero respectively? I would have thought (roughly) 300 850 and 300 280.

I'm seeing mode2 numbers that are twice the configuration numbers (600 1700 / 600 560 for when one, zero are sent by the ftdi device respectively). Are mode2's raw numbers supposed to be in microseconds?

If I use the "-A old-timings:1" option, the raw mode2 reports the same pulse space numbers as in the configuration file for one and zero.

Could there be a mistake in the transmit side of this patch? AFAICT this ticket doesn't indicate that the transmit changes were validated, only the receive.

[John Penfold]

The symptoms described suggest that an FT232R runs at half the baud rate that is set, making
the pulses twice as wide.
I have tried an FT230X on Fedora 27 and it gives the correct pulse widths. I don't have
any other types of ftdi chips to try.

Looking at the information on the FTDI website (AN_232R-01 and AN_373), in bit-bang mode
both chips clock the data out at 16 times the baud rate. The libftdi ftdi_set_baudrate()
routine multiplies the baudrate supplied by 4 before setting the chip, therefore the data
is clocked at 64 tines the baudrate set by the lirc ftdi driver.

It seems that the FT323R runs at half the speed, this is why the original version of the
lirc ftdi driver gave the wrong pulsewidths with an FT230X, the program was developed using
an FT232R based device, didn't give the expected timings from the calculations so the
program was adjusted to work correctly. Now that the program has been corrected to work
with the FT230X it is wrong for the FT232R (and possibly others). For a quick fix the
old_timings option can be used to restore the original function for the FT232R.

Why does the FT232R run at the wrong rate? This could be due to libftdi not setting
up the chip properly, but then I would expect speed problems when using it as a serial port.

[David Röthlisberger]

Yes, this commit (328f515, in lirc 0.10.0) breaks the ftdi driver for IR blasters using the FT232R chip (unless you specify old-timings:1 to use the old behaviour).

Why does the FT232R run at the wrong rate? This could be due to libftdi not setting
up the chip properly [...]

The FT232R in bit-bang mode is buggy & jittery. Only a few specific baud rates work at all, but even then, the actual rate you get doesn't match the rate you asked for, as you noticed. Even with the best supported baud rate the output is jittery, leading to "missed keypresses" (where the receiving device doesn't understand the signal that the FT232R is transmitting). These bugs can be reproduced using FTDI's own SDK (i.e. not using libftdi at all) and they were acknowledged by FTDI support staff via email. More details at https://stb-tester.com/blog/2016/05/26/ir-post-mortem