libftdi Archives

Subject: Re: Baud rate confusion

From: linux@xxxxxxxxxxxxxxxxx
To: Jim Paris <jim@xxxxxxxx>
Cc: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Wed, 20 Jan 2016 18:07:29 +0000


On 01/20/2016 04:59 PM, Jim Paris wrote:
linux@xxxxxxxxxxxxxxxxx  wrote:
Hi

On 20/01/16 03:06, Jim Paris wrote:
linux@xxxxxxxxxxxxxxxxx  wrote:
Hi

I am trying to get lirc working with my Adafruit FT232H device and
having some problems with getting the clock speed (baud) correct.

I'm trying to transmit a carrier frequency of 38KHz which is turned
on and off based on the IR pattern to transmit.

I've created a separate program from LIRC to investigate this which
simply opens the device, sets bit bang mode, sets the baud rate, and
writes a block of 4k alternating 0xff / 0x00.

I'm driving an IR LED and I have a receiver which will print out the
duration it detects the 38KHz carrier for if the frequency is close.

I'm using libftdi-HEAD-c4c9f0a from a few days ago.

If I provide a baud rate of 3800 to ftdi_set_baudrate then that for
some reason gives me the required 72K bits / second transmission
rate.  This is completely at odds with any docs I can find or the
LIRC code.
I'm not sure I exactly follow your numbers here.

For a 38KHz carrier, wouldn't you want 76Kbits/second transmission
rate?  I assume 72Kbits was a typo?
Yes it was a typo, I seem to have a mental block about typing 76 for
some reason.
You're saying that you need to provide a baudrate of 3800, which means
that it's apparently getting scaled up by (76000 / 3800) = 20
with the libftdi version.

As an experiment I tried building the same program against the FTDI
D2XX libraries which the docs say multiplies the rate up by 16.  But
to get that to give me the correct baud rate, I have to pass 15200
as the argument to FT_SetBaudRate.
By correct baud rate, you mean it's getting scaled up by (76000 /
15200) = 5 in the D2XX version?  So you're not seeing the baudrate get
multiplied by 16 in either situation?
Yes except that the FTDI D2XX example code and docs say that in bit
bang mode it gets scaled up by 16 not 5.
USB sniffing shows that ultimately both of these calls result in the
same value being passed down to the chip.
What is the value?
It is 0x4315 which according to the FTDI docs is a sub integer
divisor of 0.5 and a divisor of 0x315.

If I request 9600 baud, the values which appear here match the
values in the FTDI docs for serial port baud rates.
Can anyone help me understand why I have such a seemingly bizarre
bit rate being used by this device?
I had some eeprom issues initially with the device; is it possible
that the eeprom contents can affect the baud rate like this?
Or have I bought a fake FTDI device which doesn't operate as the
genuine ones do?
Not sure, but it sounds like you have a factor of 4 discrepency
between D2XX (scaling by 5?) and libftdi (scaling by 20?).  I also
saw this mystery factor of 4, with a FT230X in bitbang mode.  For 38
KHz IR, my code uses:

#define CARRIER 38400

   ftdi_set_bitmode(&ftdic, 1, BITMODE_BITBANG);
   ftdi_set_baudrate(&ftdic, (CARRIER * 2 / 16) / 4);

The / 4 was just something I determined experimentally and never dug
into.
The libftdi code multiplies the baud you request by 4 if bitbang is
enabled.  Not quite sure how this relates to the *16 that the FTDI
code but it does at least explain why the libftdi baud parameter is
1/4 of the equivalent D2XX baud parameter.
OK.  So this doesn't seem like a libftdi issue then.  Let's assume
we're talking about D2XX which doesn't multiply baudrates by 4.  Is
this correct:

- If you request 9600 baud, it sends 0x4138 to the device which means
   a divisor of 312.5, and the actual bitbang baudrate is 9600 * 16 = 153600
Using libftdi, I specify:
9600 baud to the library call - I see 0x4138 sent to the device - my DVM shows 96KHz (9600 "baud" x 20 bit positions per second) - consistent with the IR rates.

If I swap the baud/bitbang call order (so that the bitbang inherits the baud set in RS232 clocking), 9600 baud maps to 24.6KHz which I guess is 2.5 times - a factor of 2 different to the x5 factor observed elsewhere.

Unfortunately I don't have an RS232 level shifter to be able to use this device connected to a "real" RS232 port to confirm whether conventional serial port operation works as expected.
- If you request 15200 baud, it sends 0x4315 to the device which means
   a divisor of 789.5, *but* the actual bitbang bitrate is 15200 * 5 = 76000

If that's true then yes, this does seem like it could be a hardware
issue like a fake chip...
The remaining thing that I'm still not certain on is the eeprom content I'm using. It was mostly generated with
Jim


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
Current Thread