MAF options..
MAF options..
Any chance you can set up the blowthrough features to be actually configurable? I'd like to use the ECU+ for my blowthrough setup, but its using a Ford Analog MAF and Ford AIT sensor.. It wouldn't be easy for me to swap to a GM sensor (plus I have reservations about using a GM sensor after having several corvettes and camaros that were turbo/supercharged)
Oh and I crashed the software again while data logging, I'm thinking it may be one of my firewall/spyware tools preventing a call to a DLL..
Oh and I crashed the software again while data logging, I'm thinking it may be one of my firewall/spyware tools preventing a call to a DLL..
There's one know software crash thingie - it has to do with having the ECU+ Win application as the not-top application, and then hovering over a graph. Any chance that's what you're seeing?
Bug me about the other MAF a little bit in the future. I don't want to commit to it now since I can't get to it right away. I have some unadvertised analog inputs we could use for that, and what I'd be interested in is the voltage that's equivalent to a particular stock MAS frequency. Also, I'd need to know how to alter the MAS out frequency on a temperature basis. I'd rather do this as a fixed table rather than a generic collection of tables, since I prefer the simplicity of supporting a particular fixed, known configuration. Keeps support e-mails to a minimum
Tom
Bug me about the other MAF a little bit in the future. I don't want to commit to it now since I can't get to it right away. I have some unadvertised analog inputs we could use for that, and what I'd be interested in is the voltage that's equivalent to a particular stock MAS frequency. Also, I'd need to know how to alter the MAS out frequency on a temperature basis. I'd rather do this as a fixed table rather than a generic collection of tables, since I prefer the simplicity of supporting a particular fixed, known configuration. Keeps support e-mails to a minimum
Tom
Okay, I can work with you on that one.. And the crash, YEP, that was it, turns out I had a dialog window pop up in the foreground while the mouse was hovering over one of the graphs..
Just so you know, there are several types of calibrations for the cobra sensor, so it needs to be adjustable, but in general, the general adjustments are 0v is "standing airflow" and from there to about idle airflow it should be around 30hz, at 5v the larger sensor should read about 3000hz, the curve through the RPM depends on boost level, but is generally more aggressive at low RPM, with the curve peak at about 3000rpm, and leveling off through redline where it becomes more linear (again, depends on boost level) But that is why adjustment is needed, however the adjustments don't have to be very complex, you just need:
A graph with a curve, starts linear,
Starting value at idle hz
ending value at redline hz
curve (mid value)
and Tip-in enrichment (Value bump for tps) with decay time
and for sensor calibration you set the idle voltage, and redline voltage, in a configuration parameter.. a standard Ford Mustang sensor will closely mirror the stock MAF..
The temp compensation must also be a configurable parameter, but it seems to be +5% for every 15 degree increase, and of course, you need to be able to calibrate the temp points from cold to hot, there is some variation in sensors out there, most are the same, but you might want to offer this so you can mix and match sensors.
The main advantage is the function can be used to accomodate ANY analog sensor, and with some simple calculations, it could function as speed density since you already have a MAP sensor input, TPS input, IAT is the only additional required sensor, and RPM..
Like I said, I can work with you on this since I've done this before.
But I'll drop this until you have more time, What I would suggest you do is offer an "Engineers" menu in the ECU+ program that lets you alter internal table values that only expert users can access, this gives you the simplicity of offering new calibrations, and allows us to come up with new options, without confusing or complicating the base application.
One thing I do think the software should do, is when your logging off the sensors, you should be grabbing periodic snapshots of the OBD-II data, fuel trims, ECU perceived engine load, and ECU calculated MAF values, Pending codes and snapshots, and that stuff are great to get in the logging, and essential for producing good results.
Ever notice when you drive the ECU swings rich for a few moments? Its because the short term trims at cruise RPM's shift the long term trims slightly, and when you come to a stop (with cams) the AFR's are significantly different, if this data is logged, you can very quickly adjust the low load points and get your trims dead on..
Just so you know, there are several types of calibrations for the cobra sensor, so it needs to be adjustable, but in general, the general adjustments are 0v is "standing airflow" and from there to about idle airflow it should be around 30hz, at 5v the larger sensor should read about 3000hz, the curve through the RPM depends on boost level, but is generally more aggressive at low RPM, with the curve peak at about 3000rpm, and leveling off through redline where it becomes more linear (again, depends on boost level) But that is why adjustment is needed, however the adjustments don't have to be very complex, you just need:
A graph with a curve, starts linear,
Starting value at idle hz
ending value at redline hz
curve (mid value)
and Tip-in enrichment (Value bump for tps) with decay time
and for sensor calibration you set the idle voltage, and redline voltage, in a configuration parameter.. a standard Ford Mustang sensor will closely mirror the stock MAF..
The temp compensation must also be a configurable parameter, but it seems to be +5% for every 15 degree increase, and of course, you need to be able to calibrate the temp points from cold to hot, there is some variation in sensors out there, most are the same, but you might want to offer this so you can mix and match sensors.
The main advantage is the function can be used to accomodate ANY analog sensor, and with some simple calculations, it could function as speed density since you already have a MAP sensor input, TPS input, IAT is the only additional required sensor, and RPM..
Like I said, I can work with you on this since I've done this before.
But I'll drop this until you have more time, What I would suggest you do is offer an "Engineers" menu in the ECU+ program that lets you alter internal table values that only expert users can access, this gives you the simplicity of offering new calibrations, and allows us to come up with new options, without confusing or complicating the base application.
One thing I do think the software should do, is when your logging off the sensors, you should be grabbing periodic snapshots of the OBD-II data, fuel trims, ECU perceived engine load, and ECU calculated MAF values, Pending codes and snapshots, and that stuff are great to get in the logging, and essential for producing good results.
Ever notice when you drive the ECU swings rich for a few moments? Its because the short term trims at cruise RPM's shift the long term trims slightly, and when you come to a stop (with cams) the AFR's are significantly different, if this data is logged, you can very quickly adjust the low load points and get your trims dead on..
Ok on the MAF. We'll see what the best way to get that going is.
About the engineers menu: lots of stuff is stored in tables in the software rather than in RAM, and I only expose the stuff that people might want to change. If I let the user tweak every useless thing, the ECU+ would be, um, the AEM EMS... so we'll have to see what things are actually useful.
I do have plans to at least snapshot the fuel trims, and maybe fuel system status. The main issue there isn't the amount of data, but having to create more graphs and enlarge the engine monitor pane. I'm not sure how to handle that. Any suggestions? Maybe making the graphs and text fields multi-purpose, like one graph for "temperature" where you select which temperature you'd like to see?
Tom
About the engineers menu: lots of stuff is stored in tables in the software rather than in RAM, and I only expose the stuff that people might want to change. If I let the user tweak every useless thing, the ECU+ would be, um, the AEM EMS... so we'll have to see what things are actually useful.
I do have plans to at least snapshot the fuel trims, and maybe fuel system status. The main issue there isn't the amount of data, but having to create more graphs and enlarge the engine monitor pane. I'm not sure how to handle that. Any suggestions? Maybe making the graphs and text fields multi-purpose, like one graph for "temperature" where you select which temperature you'd like to see?
Tom
For the graphing, I would suggest starting with an overlay graph with only the major values, then allow users to add additional graphs with other values overlaid..
I found the best view of my car's operating condition was using www.dataloglab.com which basically allowed you to select the different columns of data in my log (TurboXS UTEC) and it overlaid the important data on the same graph (with appropriate scaling)
It kinda gives you an EKG like view, but when you get used to looking at 5-6 concurrently scrolling parameters, I was able to very quickly assess the car's tune..
You should consider making more data and parameters available for adjustment (as many as you possibly think is useful) but have a quick dropdown that sets "Beginner, Intermediate, Advanced, Tuner, Developer" that sort of thing, this way you don't have to confuse anyone with anything unnecessary if they don't need it at the moment.
Another interesting thing, with that new reflashing technology out there, I'd like to talk to you more about possibly doing map tracing with an ECU Rom as the "background" but I'm still trying to figure out the relationship of load (MAF Value) to the table load columns.. But thats another discussion altogether.
For me, any useful parameter is anything that has a fixed calibration at the moment.. CAS sensor, MAF sensor, Translation Table, etc...
I found the best view of my car's operating condition was using www.dataloglab.com which basically allowed you to select the different columns of data in my log (TurboXS UTEC) and it overlaid the important data on the same graph (with appropriate scaling)
It kinda gives you an EKG like view, but when you get used to looking at 5-6 concurrently scrolling parameters, I was able to very quickly assess the car's tune..
You should consider making more data and parameters available for adjustment (as many as you possibly think is useful) but have a quick dropdown that sets "Beginner, Intermediate, Advanced, Tuner, Developer" that sort of thing, this way you don't have to confuse anyone with anything unnecessary if they don't need it at the moment.
Another interesting thing, with that new reflashing technology out there, I'd like to talk to you more about possibly doing map tracing with an ECU Rom as the "background" but I'm still trying to figure out the relationship of load (MAF Value) to the table load columns.. But thats another discussion altogether.
For me, any useful parameter is anything that has a fixed calibration at the moment.. CAS sensor, MAF sensor, Translation Table, etc...
I'll say no on the single graph idea. I pretty much can't stand that type of display, and it's a headache to deal with scaling for each graph. Also, I allow multiple runs to be overlaid on top of each other with the current software, and that would also be a mess with the one-big-graph idea. Maybe what I could do is add more graphs but have a limited selection of things you could display at one time in the engine monitor display.
Tom
Tom
Not a problem.. I always found the overlay graph worked best for looking at RPM, MAF Frequency, Timing, AFR, and Boost at the same time, since I can tune from a view like that. Perhaps you can offer a limited option like that for some specific settings? these are all known scales that should be able to coexist with the right multiplier, RPM would be the largest at 9000+ but everything else I listed should scale easily within there, its not something you have to do for the user, just offer multiple data overlays on a single graph and let them choose appropriate scales.
I don't think limiting the amount of open graphs is going to change things for guys who want to see Everything.. But definitely only open the most critical ones on a new capture..
Sorry about the hard sell, I just happen to know how easy it is to get a clear picture from a single graph like that..
Graph is snatched from this thread:
https://www.evolutionm.net/forums/sh...wthrough+graph
Which is all of my R&D on the blowthrough setup I have..
I don't think limiting the amount of open graphs is going to change things for guys who want to see Everything.. But definitely only open the most critical ones on a new capture..
Sorry about the hard sell, I just happen to know how easy it is to get a clear picture from a single graph like that..
Graph is snatched from this thread:
https://www.evolutionm.net/forums/sh...wthrough+graph
Which is all of my R&D on the blowthrough setup I have..
Trending Topics
You really think that's clear? That seems like a perfect example of a confusing display to me. I can't tell what the scale is for a bunch of the graphs and I found myself spending more time telling what was what than anything else.
Note that doing this isn't technically infeasible. I just don't like what I'd have when I was done.
Tom
Note that doing this isn't technically infeasible. I just don't like what I'd have when I was done.
Tom
well in that case there is a bit more data than necessary, but for me its not confusing at all, it shows a very clear relationship to boost, maf reading, engine RPM, timing and AFR, all I'm suggesting is that it could be possible, not required..
