Oh, I will also post a universal serial capture program so anyone can capture raw data from their device (if they know their serial port settings, baud rate, etc) and save it to a file.. This will allow me to quickly add support for other devices that stream serial data without any interaction. With the captured data, another PC with a serial port, and the data settings (and some technical info from the device vendor) I should be able to quickly add new plugins for nearly any wideband with a serial interface (com port)

Another thing to note.. The biggest problem with these programs is that your not sure what com ports are the correct ones for your Wideband and other hardware. Although I cannot automatically detect it, I did the best I could, which is enumerate a list of COM ports in the dropdown, as the list would be alot shorter (typically 2-5 items) as compared to a long drawn out "testing" or finding it in the device manager. As most widebands stream data not very long after power up, you could probably find the right port within a few seconds.

Model specific plugins don't require anything more than selecting the correct com port, as the speed and handshake settings are already known. The only other settings you would have to change would be the raw log location and if you want to save raw logs to disk.. Everything else should just "work"

 

Keep up the good work.

 

And one final thought..

Any Wideband/Serial logging device Vendors or Manufacturers, if you want to get your device supported very quickly, then contact me and arrange to send me a simulator or bench unit and I can usually get the plugin coded fairly quickly. Its not so critical with this release as the components are embedded into the current code, but when unilogger is released, I can add plugins as I get the info required.

Unilogger can even log standalone EMS systems if the data stream is known or can be reverse engineered, I also plan on supporting a generic serial analog/digital IO device, its fairly inexpensive and pretty widely used for diagnostic equipment. But as its wide temperature tolerance, and ability to log analog and digital signals up to 24v, it works well with car applications.

 

that sounds really nice, do you already have the information you need for the LM-1/LC-1 support?

 

Innovate is a very open company when it comes to information, they document their serial protocol pretty well, albeit a little hard to follow, but there is enough information available for me to get the LC-1 working to start, if the LM-1 is similar it should work also, but in seeing how MTS works, the LC1 and LM1 may be identified as a different packet type. But the good news is at the rate I'm going, I'll know before the end of the month anyway.

 

that's good to hear, I know Klaus the engineer has always been vocal on their forums and was very receptive to suggestions prior to logworks 2.0. I'm sure he be willing to help if there was an issue.

 

I decided that If you select a wideband for logging, that it will append all of the data the wideband is capable of logging, as mentioned earlier, you really only should disable things if they affect performance, in this case, appending the entire wideband data and header actually takes less overhead than extracting individual values. Certain header titles will have to be altered creatively so the logs can be used without a problem, such as UTEC since there are several columns in the UTEC that are duplicate of the ECU.

This also makes the logging process much easier, as you now only have to select your wideband, and your logs will automatically reflect all of its capable data, as opposed to having to come back and add in what was left out later.

 

I'm really looking forward to the 1.5 release MJ! Will the 1.5 release be subsumed by the 2.0 if it follows only 1 month afterwards? It seems almost like a wasted effort, IMHO.

 

Fortunately its not wasted effort, as the way all of the plugins were developed happens to allow them to be pretty easily be dropped into the 1.0 code (which is where 1.5 is coming from)

The main difference is that 2.0 the MUT logging is a plugin, and not the core of the application.

Since I can't guarantee when 2.0 (Unilogger 1.0 is the new name) will be released, I wanted to get the wideband support out there somehow, it just happened to be all of the plugins I had developed were pretty easily able to be added into v1.5 using the exposed com interface. An interesting side effect is many of these plugins actually will run standalone outside of the logger. I just wanted to get another option out there for people.

But to clarify about it not being wasted effort, the reason is the code is shared almost in its entirety between both versions, so everything I have done actually is mirrored in both code sets.

 

Does this mean that there will be support for AEM WB with the serial data log ?

Regards
Gudmundur

 

Eventually there will be either a generic one you can set up to work with it, or one specific for your WB device.. The generic plugin I wrote was to collect data logs from any serial device so I could develop a logger for it quickly. If the data is just a bit of simple text streamed out, it would only take a very short period of time to make a plugin for it. If you can PM me a snippet of what a raw log looks like I might be able to at least get a development version together and put it in there.

 

I am waiting for my AEM WB but as soon as I get it I will send you a RAW log.

BTW MJ thanks for all the awesome work you do

regards
Gudmundur

 

Cool, Now that my Son is out of the hospital, and we're not expecting any new adventures, I can get back to my coding and finish up what I started..

 

Jack, I'll send you an AEM Uego wb sample from telnet. How do I get it to you?

 

You can zip it up and PM the file to me on Aktivematrix, or email me over there sysop or malibujack at aktivematrix (I don't want to spell it out because I don't want to get spammed by robots)