RomRaider

I posted an inquiry in the Romraider Discussion forum about whether there were any plans for a plugin for the Innovate TC-4 module. Given the lack of response to my inquiry, I am assuming that no such plans are in the works. I see some real value in supporting this module, as it would permit logging of up to 4 thermocouple sensors. In my case, I want to log IC inlet temps, IC outlet temps, underhood ambient temps and EGTs. Knowing the IC inlet and outlet temps will allow me to determine IC efficiency and better tune temp-based timing comps.

I have some software development experience and was wondering of it is possible for me to develop the TC-4 plugin myself. I have the Innovate SDK, but know nothing of the Romraider interface. I am hoping that it would be a relatively simple matter to start with the LC-1 or LM-2 plugin and modify it to work with the TC-4 datastream. Is this do-able?

Thanks.

Tim

If you want to give it a go... start here.
http://www.romraider.com/RomRaider/GettingStarted

Any development with this?

I just installed a TC-4 for individual cyl EGT monitoring. I'd rather not have to start a logworks and romraider log simultaneously and then combine them in post-processing if I don't have to.

I have a lot of programming experience in many different languages, but haven't delved into Java much yet. I will if nobody has made any progress on this yet though.

I believe it's just a matter of modifying the existing selection of logging items. The MTS plugin should easily read the data. It just does not know what to do with it at the moment.
Using the RC9 version can you switch the log4j.properties from info to trace mode, delete the rr_system.log and start up the logger. With the TC-4 plugged in select the Innovate LM-2 mts plugin channel 0. Then select the external for the LM-2 this will record what is available on the MTS channel.
Submit the rr_system.log file and we can go from there...

Thanks, I'll get on that in the next day or two. I'm just now finishing up the EGT installation and still need to tuck the wires under the dash and clean things up a bit, but the Logworks logging is working with the TC-4. I already see why my car is stumbling a bit at hot idle, cyl 2 is running about 100F hotter than the others (at idle at least, 1050F vs 950F), so it's likely lean enough to where it can't fully cumbust when the target is 14.7. When the target is 14.1 it idles smoothly, so I'm guessing cyl 2 is running about a point too lean at idle. Should be easy as pie to fix.

If there's still any confusion as to which cylinders map to A-D per cyl fueling and A-D per cyl timing, I'll be able to clear that up in the next day or two as well.

Also the new fast polling in RC9 is fantastic. I haven't done a quantitative comparison, but the difference is at first glance more than significant.

You deserve a cuddle!

No man cuddles thanks...
I don't need much data, just what the MTS driver reports as loggable devices in the data stream.

Here 'tis

I believe the part you're looking for starts at timestamp 149920. As I'm sure you'll see in the log file, I also have an LC-1 on the MTS system.

Got it.

Does the LC-1 report any reasonable data when selecting the LM-2 in RR?
The conversion formula for AFR is currently:
Where sample is that reported in the trace above and the multiplier is read from the Innovate controller.

Yes, when I was doing this test the values being printed for the LM-2 matched my XD-16 gauge (also on the MTS bus, set to print the LC-1 AFR).

The engine was off at the time, key on, so the measured AFR was just what was left in the pipes, somewhere around 17-18:1.

Because so many devices can pass data via the MTS stream, what might be the best approach for the user to set things up?

• First you need to set the MTS port, currently supported in the Logger.
• Then the Logger has to read the stream to gather the device data, also supported in the Logger.
• From this gathered data the Logger has to determine which devices it can support, right now it only reads data for Input 0 (AFR or Lambda, however the controller is set).

This needs to be added.

• Actively update the Externals parameter list with the devices found and a list of units, if applicable for each device in the list.
• Save these selections so they persist in future logging session.

What do we do if the device is not available in the future, remove it from the listing or retain it until it can be validated again?
How do we force re-validation?

What if you just treat the MTS stream as one device? When the user enables the MTS stream (by selecting the MTS external device), the logger parses the stream to determine what data is available on it (this could be LC-1, LM-1, TC-4, etc), and adds all of the supported fields to the log. By treating the MTS stream as the device, rather than say the LC-1 as the device, you don't need to worry about any one part of the MTS stream not being available in the future, unless the entire MTS stream isn't available (in that case you could fall back to whatever behavior the logger currently takes if the LC-1 isn't available, or any other external sensor).

This way you don't have to have separate fields in the external devices list for each MTS product, you just have one device called "Innovate MTS", which when selected, the logger will parse the stream and add all of the available fields. If the next time the user runs the logger, they've added a device or removed a device from the MTS system, the logger will recognize that when it parses the stream the next time it's selected. If a device is added or removed "on the fly" (which I don't think is possible anyway given that the type of connector Innovate uses will short out the device if attached/detached while power is supplied), they would just need to remove the MTS external device, then add it back in for the logger to re-parse the stream and add the updated fields to the log.

Since the data isn't coming through OBD-II, the extra parameters shouldn't slow down the logging rate, so I don't see the harm in adding all of them even if for this one log the user only cares about the LC-1 for example.

That would certainly make it easier to had from a GUI perspective.
True there's no impact on the ECU logged parameters as they do not share the same communications line.
So what about units selection?
AFR vs Lambda
Celsius vs Fahrenheit
MPH vs kph
The logging could be done in the native format of the stream and leave it to the user to convert in the spreadsheet afterwards, or the USA could just conform and switch to metric.

I think the native units would be fine. If the user doesn't like it they can change the native units using logworks or lm programmer, or convert afterward like you said. Or the logger could have one MTS config page with all possible data types, so the user can set that any temp measurements on the MTS are in C, any AFR measurements are in lambda, etc.

I would love it if the US would switch to metric. I do a lot of scientific programming and absolutely HATE imperial. I convert everything to metric, do what I need with the data, then convert back to imperial if necessary when I'm done. It's such a stupid units system.

FYI - I did a quick test, and at least on my ECU, the per-cyl fueling compensation A-D tables do indeed map to cylinders 1-4 (A=1, B=2, etc.)