You have to use your lap top. The LM-1 will only record the AFR and data from the LMA-2/LMA-3

 

I am increasingly impressed with what we can do with Logworks. I created a formula for IDC. I also added to target formulas that will allow us to create a floor (line) or a ceiling (line) for both AFR (AFR 10.99) and KnockSum (KnockSum 3.0). This way you can see at a quick glance if your AFR is falling below 11 or your KS is going above 3. You can set the target to any number of your choosing.

The hp/tq numbers from the posted formula came out way too high. I e-mailed DLL a LW log to see if the can provide support for LW in DLL. I hope they can do it.

I also re-edited the xml file to reflect the clean parameter names that MJ uses in his xml file. MJ's xml file is amazing; no clutter and no two word id names.

 

NJ / Others -- What does LW provide that Evoscan or Mitsulogger don't? I have read the posts, but just don't seem to understand why folks are so excited...I must be missing something...Thanks for the help & Merry XMAS!

 

Here are some of the advantages of LW:

1. You use ONE program to log everything you want. No need to use Mitsulogger/Evoscan and then have them read by DLL. Now I can have AFR, boost and all the other parameters from the ECU via tactrix on one chart. With Evoscan/Mitsulogger, I had to log boost separately with LW and could not combine the two in one chart.
2. You get REAL TIME tracing or logging. You can see the trace lines move on the chart as your car moves.
3. You can use TRIGGERS to start the log based on RPM, TPS, PSI or ANY parameter that you like. Example, if TPS goes above 50%, then logging will start.
4. You have a whole math library in the program that will help you calculate new parameters from ones already logged, eg, IDC, LOAD, maximum speed per gear, etc...
5. You get 6 realtime gauges that you can use to see what is going on in realtime. Evoscan has that, but I never used it. With LW it is automatic one you connect the guages show you the realtime numbers. Logging is separate from the gauges.
6. The ability to overlay two logs. This will show you what two run look like superimposed on one another. I found that very helpful.
7. The ability to create tables with Load as the row variable and rpm as the column variable. The table looks the same as the one in the Evo rom for high octane and timing. Then you fill these tables with AFR or timing data. Then you compare that data to the rom and see what your actual data says and what the rom is saying. Here is an example:



There are others, but these are the ones that come quickly to my aging mind.

 

FWIW, it was never our intent to nec. replace EvoScan or Mitsulogger. All and all, we do think LogWorks is a pretty decent logger, but our goal is to promote tuning - because we think good tuning requires the best possible wideband measurments and our LC-1 and LM-1 are the fastest and most accurate WB controllers available.

Right or wrong, our reasoning is that more tuning means more widebands, and more widebands means more people using our controllers. That is why we seem to work at cross purposes.

Look at me. I just wrote the plug-in to let the Tactrix cable bring channels into LogWorks. But I also wrote the free SDK that let's folks bring MTS channels (our hardware) into other applications. I know that a number of loggers in the 'open' community are using that ActiveX control - in fact, as I mentioned in another thread, the whole Tactrix cable thing was an offshoot of my efforts to help an open source effort called Enginuity (www.enginuity.org) using our hardware in their Java app.

It isn't just me, it is company wide. I know that Klaus personally helped Evo4Mad understand the serial data coming from an LC-1 on our forum backin September. And he was 100% behind more plug in interfaces in LogWorks 3. Again, the idea was not to lock people into logworks, but to proivide a platform for individuals to build on. For example, let's say Malibu Jack has a bunch of great ideas and things to add to the tuning community, but lacks the time to build a comprehensive logging application from scratch. Now (and officially in LW 3 coming at the beginning of the year) he can bring channels into LogWorks and dynamically interact with them on the back end.

If this helps him focus on specific things, great - LogWorks is free. If it turns out he wants to do his own logger or tuning application, that's great too - We'll help him with our SDK, our low level serial protocol, or whatever else he needs to support our widebands in his work.

Switching gears (pun intended):

1. P and T - the measurement I gave uses a spline based slope function. If you select just the stretch of the log that is WOT at the gear specified, the resulting traces will be much more accurate in that selected section. Of course, we're also happy to give whatever support is required for a 3rd party chart tool as well.

2. Dials and gauges. Actually, dials and gauges are unlimited - however, because of a quirk with LM-1 (which has some legacy contraints), LogWorks 2 only has gauges for MTS channels when an LM-1 is connected. This is corrected in LogWorks 3 - which has much snazzier gauges and the ability to contruct math type gauges and indicator lights.

Happy Holidays,
-jjf

 

Logworks fits a specific niche, it won't replace the other loggers simply because there are way more wideband devices out there that logworks won't log from (well, It could with a plugin)

I do intend to develop plugins for Logworks along side the plugin architecture for my software, as both have similar purpose, which is logging, but my logger is designed more for data collection and post analysis where there's alot of data to correlate in different ways.

For instance, I have a version of Mitsulogger v1 coming together specifically to log both MUT and UTEC and/or Tuner Pro data at the same time, because that is what I need specifically for my personal car. Yet I will be using Logworks 3 with the Universal Tactrix cable, and the Wideband for tuning my customers cars.

 

Actually, even this doesn't bother us. Once people understand the value of WB tuning, it is easier to demonstrate the value of good wide band measurements. If PRI was any indication, a certain segment of the tuning market already gets it. And, although there is a lot of noise in the market, I think die hard tuning communities like these will help people understand as well.

Bottom line, good maps require both accurate and responsive measurements. So, once someone is used to the idea of using, say, target vs. actual fuel maps we think it is easier to show them the benefit of having an 'actual' table that isn't shifted a column or two because of their wideband controller.

So yes, you can import lambda channels as a Virtual Device.

Going back over what I was trying to explain about Slope. I took a log nj1266 had posted and applied a little smoothing to his RPM channel. I then applied the slope based RPM to power computation to the whole log:



The measurements are weighted quite high because of the portions of the log which are not actually accell->RPM->time at the target gear ratio. So I next selected the portion of the trace that the throttle was wide open:



Notice that the measurements become much more realistic. Ideally I would highlight just the portion that is WOT at proper gear. NOTE: These measurements are also off because I couldn't remember his exact weight and gearing.

None of this is to discourage other power calculators, I'm just making the point that, with good measurements and the right application, slope based power computation from RPM can be surprisingly accurate. I've had several opportunities to try these measurements in a dyno situation and the results have always been surprisingly close.

-jjf

 

i can't wait to try this out over the weekend. I love my lm1 w/lma2!

nj1266, your boost looks like its moving around in the upper rpm range.

 

I'd certainly use Logworks with a plugin to import data from the UTEC.. I like the tool I wrote, but as long as the data can have the configurable portions adjusted, so the output is correct, then Its good with me.

 

That is the same set-up I have and I have two xd-16 gauges, one for AFR and the other one for boost.

You going to love logging with Logworks. I love to watch the trace, but I also must keep an eye on the road. I can't wait to log someone else's car.

It is prbably becuase the xede controls my boost and not an MBC, but it could be something else.

 

I do not think those numbers are accurate. There is no way that my car put that much hp and torque. On the dynojet my car puts 300 whp and about 290 ft/lb. With Dataloglab I get similar numbers.

I did add the weight and the gearing to the equation you posted and I did select the WOT sections only. The numbers were still way way high. I got 504 lb/ft and 499 hp @ 5190 rpm. As much as I would love for my car to be putting such power, it is just no correct.

 

Perhaps your log was 2nd gear and he calculated a third gear pull

 

I do not think so. His numbers and mine are close. I used 3rd gear and I think he did. Both my numbers and his are off, way off.

 

The first image of your shows a time lapse of 1.9 sec for 3000 rpm to 6000 rpm. Though time vs rpm isn't allways a good measuring tool, for 3rd gear thats screaming - over 500whpish

 

Great catch.

I'll bet his LM-1 has never been updated. Some firmware versions put out data packets serially at 1/2 rate. Most users don't have a problem because they just log on the LM-1 itself (the downloaded logs are at normal speed).

The serial packets are used as the time base, so log time is running at 1/2 rate. Since RPM over time is compressed, the HP numbers are too high.

nj1266 - if you can email me (joe at innovate-tech.com), I'm going into the office for part of the day tomorrow and can send you the dld file you need for your LM-1. Just let me know what version your LM-1 is reporting now.

Sorry I didn't notice this earlier. I typically only test with an LC-1 or a DL-32 attached and none of the serial2 protocol devices have the problem.

-jjf

Edit: Yes, the calculation is for a third gear pull.