I forgot to mention, This is version 1.5, but in Unilogger (Mitsulogger v2) you can use any combination of plugins, the plan is to support different EMS, ECU's, GPS, Wideband devices, etc, and you can log any or all data from them to a common log file, plus any data logged directly in the plugin will be synchronized to the main logs. A good example is a video capture plugin that will overlay selected logger items to it plus timecode, the video capture plugin was another bit of retired code I had written some time back for analyzing video. But thats Version 2..

For now, v1.5 is a maintainance release to offer wideband logging support for units that don't have any at the moment.

I will release a plugin framework and a simple serial logger so you guys can manipulate and log any serial data, or write plugins for anything you can think of, from graphing, dashboards, gps, etc..

 

Computer CSI................................I'd let her catch me

 

So this will include any PLX wideband devices too Im hoping

 

MalibuJack:

Was wondering if your logger will have this feature, or if you could add it soon?

Audible Knock Warning

I know that UTEC has a warning where the MIL can turn on if there is a certain amount of knock detected (lets say, 5 counts) so you'll know to back off the throttle..

I'm sure this could be easily implemented. Just give the user an option to set their desired .wav file to sound off when knock equals a user configurable value. Or even a system beep..

It would be nice to see this feature in your logger or Evo4Mad's logger also..

I'll probably be switching over to yours once this happens.. For now I'm using Evo4Mad's Gauge feature (created a digital gauge for Knock/AFR) which I can glance at while doing pulls... Would be MUCH nicer to keep the eyes on the road (audible alarm)

Just a suggestion

 

I don't really see alot of value in an alert like that simply because by the time you'd hear it, it would likely be too late.

A feature like that won't make it into 1.5 simply because I'm just doing some backfill to get some glitches worked out, and in the process of writing some plugins, and converting mitsulogger to a plugin, I found I could release some of the components combined together as a Maintainance release before I release the completely new architecture.

In v2.0, the framework and a few plugins will initially be available, however, a sample plugin with source code, and some other developer tools will be included with it. Therefore anyone with some time and the ability to write code that cooperates with the plugin architecture (VB.NET and C/C#.NET among others) can create anything you want to extend its functionality. My interest is in the core components, which is the framework, aggregator, Mitsulogger Plugin, OBD-II Scantech plugin, Enhanced Wideband plugins (Innovate LC1, Zeitronix, Tuner), UTEC plugin, and the configuration tool. Anything else will be added later once the framework is stable.

For the v1.5 release, I can only add support for devices I have physically available to me. So if PLX or a vendor of the product can arrange to lend/give me one for my bench, then it probably won't make it into this upcoming release.

 

Jack,

Will V2 plugins be limited to inputting data into your core engine or will they be able to perform operations on the results?

Couple of possibilities make me ask this:

- Conversion on the data logged into different units or whatever
- Real time guages

 

There are several different types of plugins.. Ones for Input and Ones for output, and ones for processing (Dashboards, Graphs, etc..), the only core component is the aggregator that puts everything together in one "Dataset" that can be operated on, the core handles creating logs to disk, and headers for the log files. While its logging, input plugins will start and retrieve data, the processing ones can manipulate or display data, and the output ones can take that data and be used to output other data. Any plugin can have any or all of these abilities.

So, the answer to your questions are yes, you can do those things if you wanted to make plugins for it, the potential is limitless.

Here's an additional piece of info, there are a few plugins that will be able to operate independent of the Unilogger (Mitsulogger 2.0) A good example is the UTEC/Tuner plugin, which can be launched outside of the application as its a complete standalone logger for the UTEC also. Many of the other plugins that have a useful raw output will be able to do that.

I will release a processing plugin that can be used to generate any type of data from existing data and add this data to the logs as its own output. You have to be careful with this one, but its very powerful as its scripted using VBScript, and it is very easy to work with.

 

Also, the plugin interface "Should" work with vbscript modules, I'm just trying to figure out a way to do this, as this makes it possible to create an infinite amount of plugins..

 

an audible knock alert based on a user's threshold would be fantastic, I rely on that heavily with my pocketlogger on my Stealth. It keeps me from staying in it when it's knocking it's *** off. Knock at 500 + awhp = flat bearings

 

Nice! Looks like I can adapt my logger's gauges to this...dashboard time!

Looks like you will have the most advanced logger out there. Now if it was only possible to add flashing to your logger, this would be the killer app!

 

Thats the key of the way this works, once the OpenECU ECUFlash source becomes more widely available, it would be possible to compile it so it exposes objects that would make it possible to be used from within the logger, and even better, a really proficient programmer can have it interact even more.

 

Jack - Do you have an approx release date for it ?

 

I'm hoping to get the 1.5 maintainance release out by the end of the month. The Unilogger (Mitsulogger 2.0) which is entirely plugin based, will hopefully follow some time in February, at least for the core app, aggregator, the mut plugin and a few wideband plugins derived from the current wideband code I'm finishing up now. Honestly, the hardest part is devising what type of data and how much of it, to make available as a common interface that all plugins must use. If I don't give it enough thought, then adding new interface options would make older plugins not work properly. So I want to plan for as much as possible.

 

Okay.. zeitronix logging is working, I have several things I need some opinions on..

I'm still working through some of their conversion formulas so I have to send out an e-mail and wait for a reply, but here it goes..



Anyway, as far as I can tell, Boost can be measured in PSI or Bar, and EGT can be measured in Celcius or Fahrenheit, I think the RPM output can be configured for Cylinder measure. I am planning on making all of these settings configurable as this plugin will be universal and this will allow it to work standalone for any car.

Also, the plugin is also capable of raw log output, it currently just outputs the stream of data as its recieved, but I can alter that to display comma delimited files instead.

The cool thing about it is as long as the device is "online" (15 seconds after power up) it streams data, so once it connects it will always show data streaming regardless, the current display isn't pretty, it shows what the logger output string is, which is a comma delimited string of text, for me its adequate to spot check.

Once this plugin is done, I can import it into the current version of Mitsulogger and start focusing on how the logs are displayed and how each item is handed off. I'll probably continue to use XML "fake" requestID's to indicate what brand wideband and what items to display, the current code just appends the entire header and comma delimited string into Mitsulogger, there is no difference in logger speed to have all or none of those items logged. In fact, postprocessing the string to display specific items only would actually result in more overhead.. But I'd like some input on what you'd prefer.

 

Oh, I also wanted to add that each of the plugins operates independently, therefore you could have different unique configuration settings for each of the loggers. Not only that, but all the settings are saved so you don't have to alter them each time you start the application.