NefMoto

I whipped this up last night because I was tired of using a gopro to "datalog" my AFR to RPM.  I am also too cheap to buy all the additional innovate boxes and wire them up.

It's still got a few UI bugs (and occasional issues passing ^C to the stdin to stop logging).  Most of the options are hard coded, but I will fix that soon and have something out within the next week or so.

1) It samples lambda from the LC1 at 12hz, which is a limitation of the LC1.

2) It fires up setzi's ME7 logger using the Mark P style layout and goes into a "standby" mode where it reads the stdout of setzi's ME7 logger in real time.  In my test I was sampling at 47hz.  (during this time, setzi's logger is still writing its own file to the disk.)

3) Next, it monitors the output in "standby" mode.  If the accelerator pedal position goes over 90% it takes the output from stdout, appends the LC1 data, and adds an additional microsecond precision timestamp to debug potential timing issues/drift.  It then writes this to a separate log file.  Later, you just copy the values of the logged lambda field, and paste them over the calculated lambda field, and then dump them into the spreadsheet to view the purty graphs.  No using conditional formatting in excel to find your WOT runs, and no nearly driving off the road trying to log by yourself.  I will additionally be adding a feature to use WOT as a trigger, and then continue recording for X seconds after you lift - this way you can do a multigear capture as well.

Also, I have tested the accuracy of the samples and with an hour of simulated logging, I detected an approximate 20ms drift in "favor" of my app, which means that it is logging the current known lambda at every sample output and there is no deviation.  I am guessing this is because setzi's logger uses a less precise method of calculating the elapsed time?  I am using kernel32.dll's QueryPerformanceCounter to calculate the elapsed time.

Anyway, here is a quick video showing how it works at idle.

http://www.youtube.com/watch?v=nN8gkkslpaA



edit------------------------------

Demons and bugs ahead...  I only spent a few hours on this and there are probably some annoying bugs.  The installer is probably broken.  The app probably won't start.  If it does, it won't log.  Hell, I don't know - every machine is different, and bugs are inevitable.  If you find some, let me know.  I only wrote this for my own personal use, but I think it may be useful to others.

Here is what you need to know to install and use this.

First, I am providing this free of charge.  Second, by downloading, installing, and using this you agree that I am not responsible for any damages that may result from its use.  You run this tool AT YOUR OWN RISK.

Additionally I'd like to thank setzi for his logger, and the community for their support.

Requirements:

Windows 7 (x86/x64) with .net framework 4.0  (installer will prompt if you don't have it)  It may work in XP - if it does let me know.

Innovate's LogWorks 3 installed.  Stupid, I know.  No matter what I've tried I can't get my installer to package everything it needs, so the easiest way to deal with this is to just install LogWorks 3, which happens to include the SDK and the calibration/setup tool.  Make sure your LC-1's lambda multiplier is also set correctly to your fuel.
http://www.innovatemotorsports.com/support/downloads/LogWorks3Setup.exe

setzi62's ME7 logger from here:
http://nefariousmotorsports.com/forum/index.php/topic,837.0title,.html
Note that I wrote this for the ORIGINAL RELEASE.  I will test the latest version and report back.  For now, I know that ME7Logger_DIST_29072011_v1.06.zip is tested and working.  Here is a DIRECT LINK (http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=837.0;attach=962):  

Next, you will need the mark_p_style.cfg that Complacentsee put together.
http://nefariousmotorsports.com/forum/index.php/topic,837.msg7177.html#msg7177

Last, download and install my logger.  I attached it here.

First, I would recommend to start this app with your cables already connected.  Remember which USB port you use for your LC1 and VAG-KKL cable.  The port numbers will change if you move the devices to different ports.  This will generally be annoying.  I do my best to properly locate the LC-1, but there are a limited number of scenarios I can simulate.

You will need to set some default options.  First, your LC1 should be detected, but if it's not, select the proper port, and the proper channel to use.  You may have to hit the rescan button.  And wait until the second coming of Christ for it to refresh.  Sorry... it's just how lame their SDK is.

On the main screen:

"Display as lambda" - duh - if you need an explanation... erm... uh...
"Change Colors" - This simply changes the display background color on stoich.  Red for lean, Green for rich.
"Smooth output" - one of my LC1's is older than the other and will sometimes offer jittery output.  This takes a 3 sample rolling average, resulting in a ~25ms latency with respect to current conditions.  This affects the log output as well.  Unchecked is pure and realtime data logged AND displayed.

"% Throttle Trigger" - this watches your pedal position.  Once your pedal position is >= this variable, it will start logging.

"Log Trailing (samples") - this specifies how many additional samples to capture when your pedal position is LESS than the trigger.  This can be handy for multigear runs as logging won't be interrupted on gear changes.

"Log Options" button launches the options screen.

Set the path to the ME7Logger.exe

Paste in your command line arguments.  By default, mine are:

 -p COM8 -r -R -o c:\ME7log.log c:\ME7Logger_DIST_29072011_v1.06\logs\mark_p_style.cfg

"ME7log.log" is the unparsed ME7 output.  Ignore it unless you need to look at all the raw data, minus the lambda logging"

Next, set your combined log path.  This is the file that will contain the ME7 Logger output, with the lambda values and timestamp appended.  It will also contain ONLY the samples received during the WOT trigger.

"Insert a timestamp separator before each throttle triggered log" will insert a timestamp in the combined log.  This is handy for seeing when your sessions start/stop.

The parsing options should be default unless you are using a custom layout.  If you don't know what I'm talking about, ignore this.  I determine throttle position by reading the value associated with the pedal position.  The position is 0 based and simply the first character of the throttle pedal position in your log output.  The number of characters to parse should be 2 - you can determine this from looking at logs you take manually.  Again, this is only something to mess with if you aren't using the mark p style...

"Initial samples to discard" basically captures the initial output with useful debug info, which can be later viewed on the main screen by clicking "debug window".

When you are done, click "stop logging".  This will send a control-c to the logger and GRACEFULLY exit.  If you don't do this, you will need to restart the application AND restart your car.

Youtube explanation/example:

http://www.youtube.com/watch?v=kjEs-YMCyJY

dude.  i need this.  NOW!  :)

i have my lc1 wired into their garbage ot-2.  man that thing is a total piece of trash, but i love the lc1.  please advise...  i'd gladly beta-test this.  i'm have a 1/3-time role of software developer at my job, so i can give you actual feedback...

Cool stuff. Which API are you using for grabbing the LC1 data?

I looked at the Innovate SDK a long time ago, and decided it looked like a pain to use.

Yeah, to be quite honest, their SDK is total crap.  Thanks for the VB6 example, dbags, that really helps me a lot...  It also takes about 5-6 seconds to initialize.

Tony, if I have time this weekend I'll clean things up and send you the class wrapper if you're interested in integrating it with your logger.

Initial post updated with all the info you need to know.

Additionally, the excel doc posted with the Mark P style config is screwy and displays erroneous values.  I realized it's actually the spreadsheet, not the log to blame.  So I'm going to try to fix the spreadsheet.

Good work!

I like the large letters for real-time display. But I think you should be able to switch to a graphical dial. One's mind processes that a lot better when in real-time.

Yeah, I was contemplating doing that, but didn't get around to finding a decent charting control.

As an aside, I noticed my LC-1's gauge reads about .3 AFR too rich.  I know the logger is correct because I verified it against the LC-1 programmer.

What language are you working in?

I auto-generated a C# wrapper for their VB stuff a long time ago, and then I lost interest.

C#...  basically it enumerates the ports, sets the active port, and then raises an event when data is received.  Currently I'm trying to figure out why I get some rather erroneous values returned in free air.  Not a huge deal because it works fine for wot fueling.

Just as an FYI, I tried using this on WinXP with my LM-1 and didn't have any success getting it to run.  I wasn't optimistic about the chances of it working with the setup I have, but thought I'd try.

Did you have issues with the installer or issues with it running?  Any particular error messages?

It installed fine, it ran into a problem once I tried logging.  I'll go back and set up to try and log with it again and let you know what error message comes up.

This may not be the best place to ask, but has anyone used the LC-1's "simulated narrowband" output (Analog 1 I think) to feed the ECU? I have one of these sitting on a shelf on my garage and I would like to install it, but do not want to pull a downpipe to have an additional bung added. Thanks!

There should be a boss for where the rear 02's are/were

Yea, I have to get the rears coded out first, working on that...

Yes, I simulate both primary o2 inputs from both analog outs on my 2.7

Works very well.

oh cool. you do it for both? do you have 2 lc-1's?

Each lc1 has two analog outs, I have a single turbo with one downpipe so I just offset them by .001 volts, feed to both factory inputs and then it allows me to still have fuel trims.

I've been waiting for a bit to chime in here in regards to your setup - Snowtrooper.  Let me ask you this, and it's a bit of a postulate, so I honestly just want your feedback on it.

Do you think that using the factory ecu on a simulated output from the LC-1 derives greater precision of measurement? This effect would be due to the potential increase in Signal-to-Noise ratio of the digital signal.  Is there a way to quantify the question I'm asking?  There might also be algorithms which using spectral filtering or something on the signal. [?]

I have a LC-1 and currently don't use this feature.  I may do this if we agree there should be more precision with simulated versus actual.
Any thoughts are appreciated since I know the diversity of your experience.

I do believe there is a greater level of precision than the stock narrowbands.  Yet we must all assume the a properly functioning narrowband is really really good at finding stoich.  Then again we are told by the sensor manufacture (bosch) that the more modern 5 wire wideband sensors are more accurate amd offer better readings over a wider operating range.

In the end I trust the info from these sensors 100 times more than the narrows, its expensive but if you ran two lc1s in a true dual bank fashion each emulating to the ecu I thing the car will be tuned that much tighter.  I also really like logging my car and having the primary o2 data be legit.

Also I cannot stress enough how much the signal needs to be shielded.  I like to use rca a/v style cables for each feed.  Cut off and stripped back they have the other wire  like a coax cable and if you ground the outer it works great to keep interference out.

Interesting.  So in the case of a single turbo, a single LC-1 input can have 2 separate outputs, and you can offset each output individually?

Great tool, love it worked first time.

Is there a way to log 2 LC-1s, I'm running one in each bank and would really like both in the combined log.

Thanks

Technically it should only require a minor revision.  I'll take a look at it tonight...

Are you using the LC-1's on separate serial ports or do you have the units daisy chained?

Hey mate,

I have them Daisy chained at the moment, but which ever is easier

Thanks

Let me see if I can find my stupid 2.5mm to 2.5mm cable to daisy chain mine.  Do both sensors enumerate in the dropdown list?

Yep both are in the list, interestingly I actually have 4 devices (i.e. 2 duplicates?) but it works without a problem

Hey mate,

Did you get a chance to see how hard it was to add the second LC-1?

Thanks

Actually, that reminds me, I ordered another cable but it hasn't shown up yet.  I've got some vacation coming up so I'll definitely get it working soon.

Thanks mate, didn't want to hassle was just checking ;-)

I just wanted to say thanks for this!
I got it setup and running today with my LC-1 setup.
Other than not putting the column names in for the data it seems to be working great!

Hey Jason,

Have you had any chance to see if this could be expanded to 2 LC-1s?

Thanks

I am still using this with great success.
Similar to the logging 2 x LC1 units would it be possible to also log EGT using the TC-4?
http://www.innovatemotorsports.com/products/tc_4.php

Sorry for the late response...  Been swamped at work and bought a 2012 Golf TDI to replace my 08 Wolfsburg, and then have been too lazy and in love with the new car to get the Audi through emissions.  Hopefully this weekend.

Just loaded the project and I don't think it will take much.  I may need to lean on you for testing.  PM me your email address so I can send you a test build sometime this week.

I hate to have to bring the thread back from the dead under these circumstances, but here goes.

I tried using this on XP. Installed the framework 4.0, loaded the program Jason wrote and the LC1 software as well. The program opens and gets data from my LC1. All good there. I set the write to file name and save settings just as it defaults to. No changes made to the command arugments.

Saves fine, I click to begin logging, but no samples begin to record. I know it doesn't store anything til i get above the set throttle position, but Jason's video shows it reading from the time you click start logging, then parses when the throttle is used.

Do I have to have the command prompt open in the background? I notice it is in his video. Anyone else have this issue? Its like the program doesn't like my KKL cable or can't connect to my ecu. Any thoughts?

Are you launching the logger outside my app?  Or letting my app launch it?

When it's not capturing data do you see ME7Logger.exe running in task manager?

I'm guessing the command line options are not correct and ME7Logger is dying and I'm not handling the exit code properly.

Make sure you're running the version of ME7 Logger I specified in the orginal post... It's possible setzi has made changes to the command line arguments, or data is formatted differently in the stdout in subsequent versions...  I also think I have a debug button for looking at the last few hundred lines of the stdout?  Maybe that will tell us something?  Sorry, I don't have my other laptop with me right now otherwise I'd fire it up and take a look.

The first issue was my fault. I had it directed to the wrong ME7logger.exe

Now, I have it to the point that it errors after reading 3 samples. The debugger shows:

reading config file c:\mark_p_style.cfg done
loading config file c:\mark_p_style.cgf failed
exiting

The first couple of times the program stated there was an error and must close, but the third stayed running and let me look at the debug file.

Any ideas? Maybe not compatible with XP? My framework 4.0 seemed to take forever to load. Maybe an issue with that?

Thanks for the help. Looks like it will be just what I need when I get it working. I can try my wife's laptop when I get home. Its win 7.

Looks to be an issue with the ME7 Logger...  Copy your command line arguments and run them from a dos box... if you start seeing output on the screen, it's a problem with my app.  Usually .net FW issues manifest immediately on launch.

Well, after trying just the command line arguments, that works. Just not through your program. Maybe it doesn't like XP for some reason. Will try again using my wife's Win 7 laptop.

My turn to say sorry, have been really busy with work and did not check this thread in a long time.  Just sent you a PM.

Thanks for your help, with this great tool