Thanks for the offer, but I just ordered one. Unfortunately it will take till october until it arives
(the shop maintainer is on vacation, this info appeared after buying the thing ...).

So you are saying with ftdi mode you could open your interface and connect to the ecu,
then connection breaks down during logging? That would be more than I had expected.
Do you have some logs of the screen output of such occurences? Also, is it working more
reliable when using the VCP driver or do you face the same instabilities?

In FTDI mode, it will commence logging... and just randomly die.  The little period "ticks" will stop ticking and I'll have to Ctrl-C and try again.  It's short of random but it almost always dies within 2 - 4 ticks.

In normal VCP mode it works fine aside from my "error -8" issues which I'll eventually try to address at some point.

I found a problem in the code for FTDI cables, this led to a blocked program if the ecu didn't
send any more data. I have attached just the updated ME7Logger executable with the fix.
Using this fix, the FTDI mode should behave like the VCP mode, so instead of a hanging program
you will now see also "error -8" (timeouts) if the ecu stops sending data.

The "error -8" (timeouts) are a second problem, which lies outside the logger itself in my opinion.

Just an FYI, I couldn't get a connection at all using ftdi mode, but works great using the default comm mode.  Which made me curious, what is the advantage of ftdi vs vcp in this case? Sorrybif it's a dumb question, I'm still new at this.

I am not sure if the FTDI mode has big advantages compared to the VCP mode. I was hoping it
would give an enhancement regarding the reachable communication speed (in terms of delays,
not baudrate) over the VCP mode.
The FTDI mode makes it easier to locate the cable, you don't have to look up a com port number.

Wow! I am in awe. And I cannot wait to try it out. Many thanks setzi. Looking at the contents of the .zip file, it looks so unix, I find it surprising that you had not got it working on the linux side first!

Now all we have to do is convince Nye to make an ECUxPlot that works with Gnuplot and we are almost fully organic.

Make a data extractor and manipulator that will drop graphs immediatelly with gnuplot scripts. Like what happens with excel and the usual logs that we see posted all the time.

I use gnuplot all the time and the ability to create plots with a script and drop the files in any format I want (from within the script) is great.

Happy to report this things is working extremely well. This is huge for the community. I will do what I can to provide feedback and improvements.

Found a little problem with it. When invoked the first time it logs fine. Keeping the ignition on and trying to start a new logging session does not initialize properly and logging does not start. Although it is not really a problem to turn the engine off and on, which makes it work fine again, I thought setzi would like to know.

The errors I encountered were: "Read ECU ID's ....failed" The one-time error of failing to connect with an appropriate timeout may have been unrelated.

My setup for this test was: WindowsXP untouched since 2006, Cygwin untouched since 2006, Abox on MY2000 (late model) in which I had flashed the Abox file ending in 345 (from the stock ECU files of Nefmoto). I will try to run it from the linux side with Wine.