UTEC Tuner AFR logging + attn kascade

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

kascade,

I've finally got the UTEC side of logging and other functionality coming along well. I'll update my other thread with those features later when I'm done with one painful bug.

What I'd love to do in the interem is to get your logging facility to recieve and append Tuner AFR data to the logs. I have absolutely no idea how to approach this in your code as what you've done is complex... and I'm lazy.

I've provided an interface as follows:

Code:

package RomRaider.logger.utec.commEvent;

public interface UtecAFRListener {
   public void receivedUtecAFRData(double newAFRReading);
}

Everytime I get AFR data from my tuner, I call this method. If you had an easy way to...

1) Implement this interface somewhere.

2) Have some sort of check box for "Log Tuner AFR", menu, checkbox, otherwise. If no tuner is present and this check box is checked, then only 0.0's would be outputted to the logs, etc (keeping the interface simple for now).

3) Append Tuner AFR data to the logs, maybe even some graph goodness.

There might be some data sync issues, though not enough to worry about really. Suppose you might get AFR data from the Tuner, store it, and when the next set of data from the OBD2 connection comes along, append the logging data.. and keep appending that Tuner data regardless if its updated or not as the refresh rate of the Tuner is somewhat slower that the OBD2 data.

If this is easy to do, then please let me know how, otherwise, I think this Tuner AFR sensor would be a welcome addition to the AFR sensor family that RomRaider supports.

phew... time for bed

Thanks dude.

EDIT: Suppose a PM would have worked also... :oops:

really bedtime.

drees · **Posted:** Tue Feb 27, 2007 4:02 am

Tgui wrote:

EDIT: Suppose a PM would have worked also... :oops:

really bedtime.

No way, man, keep all the good ideas flowing out in the open.

This is open source, after all!

themadscientist · **Posted:** Tue Feb 27, 2007 8:44 am

To help match up the data wouldn't you wnat the RPM sense from the tuner hooked up? To run the tuner in stand alone mode you have to wire the rpm from the tuner to the ECU.

kascade · **Posted:** Tue Feb 27, 2007 9:11 am

i'm thinking it would be easier for the ecu logger to request the utec afr value each time it receives a response from the ecu. this would take care of synchronisation issues by default. that would mean you'd have to implement an interface something like this:

Code:

public interface ExternalDataSource {
    String getName();
    String getDescription();
    String getUnits();
    double getData();
}

or something along those lines. Your implementation would then be registered with the logger as an external data source and automatically be queried for data and be listed in the parameter list.

i hope that's a bit clear..?

qoncept · **Posted:** Tue Feb 27, 2007 10:33 am

That sounds good, but what about when someone wants to log their UTEC and they don't have an OpenPort?

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

kascade wrote:

i'm thinking it would be easier for the ecu logger to request the utec afr value each time it receives a response from the ecu. this would take care of synchronisation issues by default. that would mean you'd have to implement an interface something like this:

Code:

public interface ExternalDataSource {
    String getName();
    String getDescription();
    String getUnits();
    double getData();
}

or something along those lines. Your implementation would then be registered with the logger as an external data source and automatically be queried for data and be listed in the parameter list.

i hope that's a bit clear..?

If this makes it easier for you, then no problem

I see your point. Then while we are at it.

Code:

public interface ExternalDataSource {
    String getDataSourceName();
    String getDataSourceVersion();
    String[] getLoggerNames();
    String[] getLoggerDescriptions();
    String[] getLoggerUnits();
    double[] getLoggerData();
}

This would take care of qoncepts question. What if no open port, and they want to log utec data. The above modifications would give you all the data available including wideband (if present). This would be nice as its common for Utec/Tuner people to do custom logging devices using the Tuners analogue/digital inputs. (meth on/off), 2nd/3rd egt etc

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

Here are a few points after further thoughts.

Code:

public interface ExternalDataSource {
    String getDataSourceName();
    String getDataSourceVersion();
    String[] getLoggerNames();
    String[] getLoggerDescriptions();
    String[] getLoggerUnits();
    String[] getLoggerDataRanges();
    double[] getLoggerData();
} 

For user defined logging inputs on the Utec side using the open ports provided, I think it would be appropriate to define valid data ranges for both error capturing and graphing purposes.

What I do internally with my custom Utec logger is have a String array with the following:

(made up data ranges)
[0<>15,-1<>1,-11<>26] where "<>" is the whats used to divide the ranges. Hell, it could be anything, but this is what I chose in a sleepy haze. I'd provide this in the getLoggerDataRanges() method.

Also:

We would of course need registering and deregistering methods on your end. Some thing like:

Code:

// When a user registers you could make logging options derived from the getters in the interface above.
public void registerExternalDataSource(ExternalDataSource externalDataSource);

// When a user deregisters you could remove the external loggings availability.
public void deegisterExternalDataSource(ExternalDataSource externalDataSource);

I'd register with your logger once the Utec user selects the appropriate com port on my little gui and the user selects my "Start Logging Utec" button. When the utec user exits my gui, or forces the close of the port in use by the Utec I'd deregister.

Does this sound sane?

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

themadscientist wrote:

To help match up the data wouldn't you wnat the RPM sense from the tuner hooked up? To run the tuner in stand alone mode you have to wire the rpm from the tuner to the ECU.

With kascade asking my code for the latest value, I don't think we'll need RPM data. It might help sync up the AFR data a little better, but thats assuming the UTEC RPM and AFR data are synced to start with, which I have a feeling they're not.

I can't wait though! Finally, AFR logs for me! Also I intend to get an EGT hooked up to my Tuner, along with the upgraded knock sensor thats been sitting in my glove box for 1year. Talk about the ultimate tuning package!

crazymikie · **Joined:** Mon Feb 13, 2006 6:27 pm **Posts:** 226

Does the Tuner just send AFR readings as ASCII serial data?

If so, the same method should work with the AEM wideband. I think it runs at 9600 baud N/8/1. If the tuner works the same way, I'd be interested in trying this out with my AEM.

Let me know.

Thanks!
Mike

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

crazymikie wrote:

Does the Tuner just send AFR readings as ASCII serial data?

If so, the same method should work with the AEM wideband. I think it runs at 9600 baud N/8/1. If the tuner works the same way, I'd be interested in trying this out with my AEM.

Let me know.

Thanks!
Mike

Yes it does. Sounds like AEM has the exact same port configuration also. Once the Tuner is running with the logger, I'll pull out the relevant code to add the AEM. So I can start thinking about it, can you post an AEM WB log so I can start thinking about what you'll need?

crazymikie · **Joined:** Mon Feb 13, 2006 6:27 pm **Posts:** 226

Sure- I'll dig one up.

Basically, to log with the AEM, you use hyperterminal. It outputs a list of AFRs like:

14.70
14.67
13.23
13.23

etc.

I can find the exact comm protocol when I get home.

Mike

themadscientist · **Posted:** Wed Feb 28, 2007 8:25 am

Tgui wrote:

themadscientist wrote:

To help match up the data wouldn't you wnat the RPM sense from the tuner hooked up? To run the tuner in stand alone mode you have to wire the rpm from the tuner to the ECU.

With kascade asking my code for the latest value, I don't think we'll need RPM data. It might help sync up the AFR data a little better, but thats assuming the UTEC RPM and AFR data are synced to start with, which I have a feeling they're not.

I can't wait though! Finally, AFR logs for me! Also I intend to get an EGT hooked up to my Tuner, along with the upgraded knock sensor thats been sitting in my glove box for 1year. Talk about the ultimate tuning package!

Depending where in the exhaust the sensor is will depend on how much delay there is between what the sensor reads and what the AFR is at any rpm point. The Utec logger that navybluesubaru wrote has a user settalbe delay to help sync up the AFR and RPM. And I though the UTEC and Tuner did sync up using a time base.

TMS

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

themadscientist wrote:

Tgui wrote:

themadscientist wrote:

To help match up the data wouldn't you wnat the RPM sense from the tuner hooked up? To run the tuner in stand alone mode you have to wire the rpm from the tuner to the ECU.

With kascade asking my code for the latest value, I don't think we'll need RPM data. It might help sync up the AFR data a little better, but thats assuming the UTEC RPM and AFR data are synced to start with, which I have a feeling they're not.

I can't wait though! Finally, AFR logs for me! Also I intend to get an EGT hooked up to my Tuner, along with the upgraded knock sensor thats been sitting in my glove box for 1year. Talk about the ultimate tuning package!

Depending where in the exhaust the sensor is will depend on how much delay there is between what the sensor reads and what the AFR is at any rpm point. The Utec logger that navybluesubaru wrote has a user settalbe delay to help sync up the AFR and RPM. And I though the UTEC and Tuner did sync up using a time base.

TMS

Thats something to keep in mind for sure. I'm just trying to get this out of the door. If we find AFRs are delayed too much, then I'll take a stab at alleviating the delay.

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 1025

Thoughts kascade? :

kascade · **Posted:** Tue Mar 06, 2007 9:05 am

ok, i've implemented this in the logger with some slight modifications.

You'll need to finish the implementation of the class RomRaider.logger.utec.plugin.UtecDataSource to hook into the UTEC data. UtecDataSource is an implementation of the interface ExternalDataSource:

Code:

public interface ExternalDataSource {

    String getName();
    
    String getVersion();

    List<ExternalDataItem> getDataItems();
}

which needs to return a list of ExternalDataItem's. These are defined as:

Code:

public interface ExternalDataItem {

    String getName();

    String getDescription();

    String getUnits();

    double getData();
}

As an example I have provided a very basic TestExternalDataSource class which just returns random values from its ExternalDataItem implementation.

It is all integrated into the gui, file logger and profile management by default. Additional external sources can be added at will either directly into the codebase or via external jar files. This is possible because the logger dynamically adds additional external datasources based on the presence of *.plugin files in the plugin directory. There is one file per data source which specifies the data source class name. note that a data source may support multiple data items by just returning each of them in the list via the getDataItems() method.

I have only tested it quickly for the moment but it seems to work fine so far. i had to use a couple of small hacks to get it in but they are pretty well restricted to a single class in the bowels of the logger.

hopefully this should open up the way to integrating the LC-1, etc too - whatever happened to the code for that anyway? i'm still waiting...

anyway, let me know how you go.

RomRaider

Forum rules

UTEC Tuner AFR logging + attn kascade

Who is online