1. Ben Bass
  2. pylibftdi
  3. Issues
Issue #11 open

FT232H serial mode unreliable

Ben Bass
repo owner created an issue

Not clear where in the stack the problem lies, but serial loopback using UM232H is unreliable - sends ~29 characters and loses the rest, regardless of baudrate.

Investigate the cause and fix - pylibftdi should smooth over any differences required with respect to older devices (FT232R etc)

Comments (7)

  1. Ben Bass reporter

    Note that the latest release (0.13) gains an additional example module - running python -m pylibftdi.examples.serial_loopback (with a Tx->Rx loopback) tests passing random strings of different lengths (1..50 bytes, then 1000..5000 in steps of 1000) and checking the result is received.

    It currently fails.

    But that's really because these are stream devices and I've not got it set up for checking the data is streamed properly, assuming it's going to be more datagram-like.

  2. David Fokkema

    I'm having serious issues trying to read out a Trimble Resolution T GPS board. It's interface is an FT232R, and I use it by simply instantiating a Device(), and calling read(). Either Trimble's documentation, the firmware, or pylibftdi serial communication is seriously broken.

    Any progress on this bug? I'm using pylibftdi successfully to read out the other port on the same device (that port uses a more modern FTDI chip), and have been very happy for the past year or two.

  3. Ben Bass reporter

    Hi David, I've not seen any issues with FT232R devices, just some oddities with FT232Hs. How big are the read()s you're doing when you see issues? Do the lost bytes appear 'regularly' (e.g. repeated at a particular offset within chunks of data) or randomly? pylibftdi's read is a fairly superficial layer over libftdi's ftdi_read_data, which just does repeated bulk USB transfers to read data...

  4. David Fokkema

    Hi Ben, sorry, I'm getting lost in al the similar device type names.

    TL;DR: reads are about 62 bytes, and repeated as fast as I can. Bytes appear to be lost randomly, already in the first read. Data rate is not high (about 150 bytes per second).

    I'm reading out messages which should be 21 bytes, by scanning for start and stop codons. I regularly get messages which seem to be way too long, and I'm working on the assumption that (part of a) stop codon went missing. That seems to fit with my results trying to make sense of the actual messages. Sometimes, I can decode the message, sometimes, it is just a mess.

    I've compiled libftdi and am now running Jessie on a raspberry pi with libusb 1.0.19 and libftdi 1.2 and pylibftdi 0.15.0. I'll check on my Mac next, but that'll be a while.

  5. Ben Bass reporter

    I've done some quick tests treating the device more as a stream, rather than assuming that any particular read() call will return any particular content, and it looks promising, but it'll probably be about a week before I've got this sorted nicely.

  6. Log in to comment