Anyone ever get this?
I've been attempting to log my drives to and from work but keep getting weird Timeout errors after I start logging.

Thinking it may have to do with baud rate or something. I attempted to change the timeout setting but it really didn't do anything.

Ideas?

 

Can you give more detail about what program and platform you're using?

I have been able to log for over an hour at a time.

d

 

What else is running on the computer when your logging?

I used to get the timeout all the time when I was logging and running something else in the background.. Seems like the disk writes were distracting the serial interface just long enough to time out. This was actually the original reason I started to write my own program to log the data, since I needed something that would not timeout or die.. Every time I'd log for more than a short duration of time (my drive to work) and was also logging with my other tools at the same time, it would time out..

I had posted about this awhile back, but I kept getting the "I don't see a problem" answer... and in reality, its not a problem, its just how the program handles error conditions when the port doesnt respond momentarily.

 

Really? I modern machine shouldn't have this problem if properly scheduled. I'll be the first admit that the apple-of-my-eye-OSX has _terrible_ performance with more than about 4 threads a time. I maintain though that a correctly written logger thread should not be timing out, even with several other programs pounding the disk, hogging the CPU, and using lots of fined grained timers.

d

 

This was actually something that the author of the ECU+ software had noticed, disk writes would suspend serial activity, with a very short timout, the port will not wait long enough for the writes to finish before the connection times out. Its not really a "problem" just some of the compromises you have to make to get good performance.

In my application I had chosen to handle the error by reattempting to access the port until the logger is stopped.. It recovers most of the time so it works.

 

I suffered from FTDI timeouts for a while. Laptop would start logging but almost every time I attempted a run it would timeout. I eventually realised it was the hard disk protection on my IBM thinkpad! Turn the protection off and it never misses a beat now. Just a thought...

 

Ah!
That's probably it.

I just started a new job. IBM T60 thinkpad with HD protection.
Never would have guessed. Awesome-O.

 

I'm not sure I understand the behavior you're describing. Are you saying that the write() call to the log file blocks long enough to time out the device? It sounds to me like the filesystem isn't buffering like it should be. I certainly don't experience anything like that on OSX, linux, or solaris.

If people are seeing this happening, then the correct solution is to have two threads: one filling a memory ring buffer, the other writing that buffer to disk.

d

 

I too have the same issue when logging with the LM-1. it times out after 15min, stupid thing, annoys the hell out of me EvoScan v0.98 will have this fixed by both extending the time out, optimising the log writes, and also adding a tickbox option for auto reconnect.

 

Worked fine on the way home. Thanks guys.

The LM-1 is supposed to log 44 minutes I think.

 

Its not the filesystem buffering or anything like that.. Everything on the PC is interrupt driven, but in order to get the best performance out of the FTDI interface, its necessary to set very short timeouts for data and connection, I worked around it by ignoring the error when its thrown and continuing where it left off.

It just happens to be that when you have alot going on at once, serial communications gets a low priority. Since the FTDI cable doesnt use flow control, or any real error checking, the data doesnt get buffered for more than a few bytes before it can get a timeout error. Understand that this is because the MUT protocol is very interactive, every request expects a response, and if you want good sample rates, you have to minimimze everything, including timeouts, by doing that, you run the risk of anything taking priority stealing away just enough time to cause the interface to time out.. It just happens to be that disk writes steal away just enough time because it gets higher priority and can take a little longer.. In general, the more stuff that shims itself into the disk drivers, the longer those writes take (Antivirus, Disk protection, encryption, etc..) so if you have timing sensitive applications, they tend to timeout on rare occasions..

Most of the time, with regular serial communication you just set up a ring buffer and just que up the data, and use it as needed.. But without any flow control, and handshake, the only "sanity check" you get with the MUT protocol is its echo response to determine if the request is correct..

 

Oh, and FWIW on Evoscan, if you manage to configure the Tactrix cable to be com1 or com2, you can use that instead of the FTDI interface, and the timeouts won't affect it anymore.. Unfortunately you are limited to two com ports, and I dunno about you guys, but my Modem and Serial port take up com1 and com2 on all of my older machines, and the newer ones seem to have Modem and IRDA interface on com1 and com2..

BUT if you have that big of a problem with FTDI timeouts with Evoscan, you can use a serial port instead.

 

How short are you talking here? I wouldn't expect this to happen unless the timeout is set insanely slow (on the order of a few us).

I've never gotten a peek at the NT kernel, but my understanding is that it should handle this kind of load pretty well -- especially with DMA disks.

d

 

I can't speak for Evoscan, My app doesn't time out like this, but I do have all of the timeouts set pretty low, but not low enough to have a problem.. I just tuned the settings until I got the best performance out of the interface.

 

trying to log for the first time and get

Info: Initialising At 5 baud 0x00...
Info: Initialisation Complete...
Info: Waiting for INIT Response...
Error: FTDI Read Timeout
Info: Datalogger Ended.

using evoscan.8

please help, need to log asap