Re: LF: PIC-based GPSDO with A/D converter / supported serial baudrates ?

[Andy Talbot <andy.g4jnt@gmail.com>]

Hit send too soon ................

mutter, mumble........

The following results were obtained :

Requested         Frequency

Baud rate           Generated

3M                     146xxx      (it wobbled)

2M                     975xxx     (it varied)

1M                     500000

800k                  400000

500k                  250000

480k                  240000

So it looks as if the FTDI Chip's  FT232 family is eminently useable to 1M baud

With a 12 bit A/D and some framing, for two bytes per sample, that means you could send 0.5M Samples/  second

16 bit sampling plus framing will need three bytes, so call it 300kS/s

Andy  G4JNT

On 17 February 2016 at 15:23, Andy Talbot <andy.g4jnt@gmail.com> wrote:

I've just made some tests on the FTDI232 chip at high baud rates.

Using a custom routine written in  PowerBasic (CC) , I used that language's own interpretation and interface to the driver to pass arbitrary baud rates to the chip.   With the device set for 8 data,  1 stop bit and no parity, I repeatedly send the character 0x55 in a continuous loop.  This pattern of bits, if sent contiguously (characters are sent LSB first)  should therefore result in a square wave being generated at a frequency exactly equal to half the specified baud rate.

The FTDI232 data sheet states that baud rates are determined based on a 3MHz input to a divisor of (N + M/8, where N = 2 to 16384, plus two special cases on N = 0 and N = 1 for  3Meg and 1Meg rates respectively.   This setting is hidden from my application, and happens transparently based on the baud rate I specify beign passed to the driver via PowerBasic. 

The following results were obtained :

Requested         Frequency

Baud rate           Generated

1M                     500000

2M

On 12 February 2016 at 17:59, Wolfgang Büscher <dl4yhf@freenet.de> wrote:

Thanks Andy. I wanted to keep it simple (but not necessarily stupid), by using available hardware. In my case, the dreadful (and, most likely, "faked") Prolific USB <-> RS232 adapter.