libftdi Archives

Subject: Re: Data loss while ftdi_read_data() from FT232RL

From: Venkatesh Shukla <venkatesh.shukla.eee11@xxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 5 Jun 2014 03:29:40 +0530
Sorry for the late response guys.

On Tue, May 27, 2014 at 10:16 AM, Rogier Wolff <R.E.Wolff@xxxxxxxxxxxx> wrote:
On Fri, May 23, 2014 at 04:33:31PM +0530, Venkatesh Shukla wrote:

> The library libdivecomputer does use /dev/ttyUSB* efficiently to
> extract data from the device. But I have to do the import part on
> android platform. Android does not provide access to USB devices as
> normal linux systems do, and native code is preferred, I have decided
> to use libftdi for the import part. It does indeed work on the android
> emulator after getting requisite permissions but there is this data
> loss error. Any way out.?

Ah! New information! You're using an emulator inside a host computer!
Does the problem also happen "in real life"? I can very well imagine
that the emulator is occasionally too slow to handle the data before a
buffer overrun happens.


Yes indeed it does. Android is the ultimate aim. But currently I am using this script on my system (Fedora 20). It gives the same result on emulator as well. But with greater losses.
 
The ftdi chip knows that "libftdi" has not read the data. So it will
try to convince whatever is sending the data to stop. But there is
only so much that it can do: I expect that RTS/CTS are not connected
inside the dive computer meaning that the processor in the dive
computer will simply continue to send data even when the FTDI buffer
fills up.

Can you synchronize in the datastream? Can you download that header
multiple times to see if you're missing the same parts every time?  Or
maybe just download it once correctly using "libdivecomputer"? Compare
the data!


Yes. I am attaching the logs of both the code I have written and libdivecomputer generated logs. Also, for the sake of comparison, I am attaching combined logs of both. The first line in each pair in the file represents the data from libftdi and second line from libdivecomputer.

As I observed, 44 bytes are missing at offset 0xFE (line numbered 26) from read_data command.
Then again, 48 bytes are missing at offset 0x21C (line numbered 46) from read_data command.

For the rest of the logs, it is impossible to check for missing as all the data constitutes of 0xFF.

Regarding version of libusb being used, libusb-config --version command on my system gives output 0.1.12.
 
--
*Venkatesh Shukla*


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


Attachment: import_ftdi.logs
Description: Binary data

Attachment: import_subsurface.logs
Description: Binary data

Attachment: compare_logs
Description: Binary data

Current Thread