NefMoto

I am not able to log sucessfully. Connects OK but always fails after a few samples with error -8.

I have tried reducing baud rate, reducing sample rate and adjusting FTDI latencies with some effect but still unusable.

Any ideas what else I can try?

Shell output of three different attempts attached.

All logs show that the ecu stops communication completely at a random
point in time and nothing is received anymore from the ecu.
I faced exactly the same behaviour with my configuration!
The problem will be less often happening when the packets sent by the ecu are smaller
(i.e. log only few variables) and the sample rate is HIGH enough so that there are not
many idle times on the K-line. Obviously this all is not a useable workaround for logging.

I got just around this problem after installing a switch that allows me to disconnect all other
devices except the ecu from the K-line. If there is only the ECU connected to the logger,
it works perfectly. Up to now I don't know which device is disturbing the K-line.
Would need a  log of the interface when this problem happens (using a logic analyzer)
to find out more.

Cheers Setzi,

I have a logic analyser here. Should I log the K-Line during on of these attempts?

Would be really great, if you have the possibility to hook on a LA to the K-line
in addition to the tester. At least a log should give a starting point for further
analysis what happens on the line.
You could keep the comm speed of the logger at 10400 and (as far as the
capacity of the LA allows) log the communication until you see a timeout.

Right. I'll see what I can do.

No joy. For some reason my Saleae logic is forcing my laptop USB ports to operate in low speed mode stopping we sample anywhere near fast enough. I've tried fannying around with drivers but ran out of time.

I can log fine with my desktop, but obviously with the ECU removed the error 8 problem is gone anyway.

This will have to wait until I can get another laptop.

Thanks for your efforts, really nice you spent your time trying to run the LA.

Is it possible you have a HDD suspend/protection feature (from shock/g-force) on your laptop?  That gave me huge troubles with ECUx until I remembered to disable it.

I dont think that's my problem but it won't hurt to have a look, cheers.

For the record, I am plagued by the same ERROR -8 issues when enabling different variables.  Whether or not this is a result of "too many" variables (ie. too much data) is something I have not tested yet.  To me it always seemed that there was a handful of usual suspects so to speak, so that when I enable them, the error always happens.  I will attempt to isolate some of the variables that I considered a usual suspect into a single config consisting of only a handful of variables to test whether or not this is a K-line throughput issue.

A lot of work went into solving the issue of getting no response from the ECU in the NefMoto flashing software.

In my experience, many different situations can cause the ECU to not correctly receive or respond to a request. All you can do is try to make the logging software recover when something goes wrong.

This is interesting. I'll try a minimal variable set and see if it makes a difference.

Yes, I believe the error recovery must have been really a lot of work.

For the logging, there is not much recovery support during the setup phase -
if the ecu would not respond correctly to a message, the startup would fail.

But once the logging is running, it can recover from errors which are "recoverable":
the logger sends a log request and expects an answer message from the ecu.
If the ecu sends an incorrect answer or does not answer at all, the logger will
give a short pause time (about 55ms), clear all input buffers and then send
again a request. Only after a certain amount of repeated requests with no further data
received the logger will give up.

I think what Carlossus is facing (and what I faced in my setup initially) is that the ecu just stops
talking "forever", and the only recovery here would be to restart the complete communication.
An automatic reconnect feature could do that, but I prefer seeing a stopped logging session
over a log with a hole in it lasting several seconds.

Interestingly EcuX logs just fine, but the available variables are pretty inadequate.

I'm interested to see how Tony's logger performs.

Hey, that is fine. Would you be able to produce a serial port log of such a logging session?
Argdub produced such a log some time ago, but I don't know which program he used
to do that. Probably some kind of comport logger ...

I'll see what I can do. Logging only works properly when 'Port' is set to 'USB' rather than a real COM port number that reflects the Virtual com port. 'Baud' is set to '125000' and 'connection method' is 'accurate'.

Time is sparse though as I have a newborn human to maintain :)

Congratulations Carl! Don't spend your time on sitting in the car & taking logs ;).

I found that if my logged "data size" is over 40 bytes, the ERROR -8 eventually appears within 10 seconds of logging.

Currently I'm logging fine with:
   "Logged data size is 36 bytes."

[Communication]
Connect      = SLOW-0x11
Communicate  = HM0
LogSpeed     = 56000

So,

Somehow got a nasty rootkit on my machine while messing about with various serial spy software. That wrote of Friday. Abandoned that idea :D

I managed to beg another laptop at work to try to get some LA logs of the timeout event. As is the way of these things, it is now logging flawlessly (so far).

Because I am away from home I  re-downloaded ME7Logger, my ORI and regenerated the .ecu and template files. Installed FTDI VCP driver from scratch on a pretty much clean XP machine.

The only other difference is that this time I used the template generated from my own ORI, before I
was using the basic 4 cylinder template.

Logging about 24 variables at 20Hz seems fine. I'll push these up a bit and see how we go. Also, attempt to copy the configuration on my own laptop and see if it still works.

EDIT:
My joy was premature. Added another 6 or so variables and now it is as it was before, timeout after  only a few samples. Oh well at least I can recreate both situations for the logic analyser.

This is exactly what I said already about this problem:
The problem will be less often happening when the packets sent by the ecu are smaller
(i.e. log only few variables) and the sample rate is HIGH enough so that there are not
many idle times on the K-line. Obviously this all is not a useable workaround for logging.

The problem is, most probably in your car the instrument cluster acts as a gateway
and blocks some kind of communication. It seems to me the "Gateway" checks somehow
for "KWP1285 compliant" traffic, getting confused by KWP2000 traffic.

If you want to analyze with a LA, you should connect it once together with the logger to
the diagnostic connector and then connect for comparison directly to the ECU's K-line wire.
I would bet what you will see is:
in the first case you just see no more messages from ecu side when the timeout happens.
in the second case you see the ecu still sends response messages (not appearing at
the diagnostic connector, blocked by the gateway).

You can verify this theory by two ways:
1. Turn on ignition, then turn off ignition. The ecu still is running for several minutes.
   Now connect the logger and log big packets -> this will work fine, since the "gateway" is
   switched off.
2. Connect the logger immediately at the ecu's K-line wire -> the logging works perfectly
   even for the biggest data frames, since the "gateway" is no longer in the way.

I have verified that this is indeed the behaviour of my system.

I really can't face pulling out the ECU so I am going to live with this. Setzi, If there is still any value for me to sample the K-line during a timeout then I will, but I can't get to the ECU side of the bus without some problems.

It also occured to me that in my case ECUx logs relatively few variables, probably few enough to be around 30 byte packets which seems to work fine with ME7L too.

I don't think a sample log of the K-line will provide more insight now,
it will most probably just show that the cluster is "disturbing".
Yes, getting to the ecu cables is lots of work. Easiest place
to access the cables might be below the steering wheel, above the pedals.

Hopefully there might be a way to tell the gateway to "shut up and pass
all data".

I got a reduction in timeout errors by switching to the fastest baud in the ECU definition file and logging fewer variables. I'll still occasionally get timeout errors if I try to log too many variables at the same time. But it'll still log long enough to get data for a single run. Timeout again? Hit the up arrow then enter in the command line to start it back up with minimal fuss.

If you're trying to log tons of variables I've had great success with pulling fuse 11 (instrument cluster) on my MKIV GTI. Of course nothing will display on your instrument cluster so be careful! Also don't do this if you don't have VCDS or some other way to clear the airbag controller's "no ecu communications" code. I generated a 30MB log file testing this on a late night drive.

Thank you setzi - This application is amazing. You are a very talented programmer!

I couldn't even connect with my genuine Ross Tech interface (with boot in intelligent mode unchecked) with port set to USB, so thinking that might be the problem, I have ordered a dumb eBay 409.1 KKL cable. I downloaded FTDI Virtual COM port drivers just in case.

I had prepared a 127 variable sub-set with a plan to log at 5 samples a second but seeing this thread leaves me strongly discouraged that I can get this superb piece of software working at all.  :'(

TTQS

No, on the contrary. This thread shows a workaround for the worst case. A workaround that still provides a solution you can't achieve by other means.

Your FTDI cable + drivers will work 1st time I'll bet. Don't fanny around with low sample rates, the real value is at 20+Hz in my opinion.

O.k., thanks for the encouragement. If it works, it will be tremendously exciting to get into all those parameters at such high data volumes.
Thanks.

TTQS

Received the cable today and sure enough it worked first time with my 127 variable template. I experienced a few disconnections but after a successful continuous logging session over maybe five minutes, I figured this was because the cable was coming adrift either at the OBDII port or the USB port because it's only just long enough to stretch across the footwell to the passenger seat. I'll post up the log on carlossus's statistical load bearing dyno thread later on.

Thanks for your advice guys.

TTQS

I'm also having a problem with connection. The car is Audi S4 with 8D0907551D.

The program works fine when ignition is off but right away when I turn the ignition on the connection gets lost. I also tried to connect when the engine was already running: no connection at all.

I think that the number of logging variables doesn't affect because I couldn't maintain the connection even with only one variable.

I'm using VAG KKL USB cable and have installed the FTDI VCP driver.

What should I try next?

Try pulling the fuse for your cluster to see if it makes any difference while ignition is on.