legacycentral bbs

Posted: **Wed Feb 16, 2005 11:00 pm**

Well, I've actually learned more since the last revision of the scantool, so you'll actually have more in this box than my scantool does.

Posted: **Wed Feb 16, 2005 11:05 pm**

Sweet. Man this is the way to develop a product. A board of enthusiasts making suggestions for features that are no problem to add once the basic functionality is in place. I wish I could devote a good chunk of time to this project sometime soon, but unfortunately (or fortunately) I have some pressing paid work to do

I'm making sure to keep good notes and comments in the code though so no feature will be left behind...

Posted: **Wed Feb 16, 2005 11:07 pm**

Hey - your scan tool, although it uses the parallel port, is really sending and receiving serial data isnt it? Is it RS-232 or I2C or something like that? I can do that on the PSoC - perhaps I can pull a good portion of the measurements off the serial line like your scan tool does, that saves quite a bit of resources for other amazing features which I'm sure we'll come up with in this discussion...

Posted: **Wed Feb 16, 2005 11:37 pm**

Yeah, it'd definitely a great way to do a project. I'm very familiar with the things-being-pushed-back-because-of-Real-Life thing too.

The diagnostic data is indeed serial. It's a TTL version of RS-232. That's probably exactly what your microcontroller does anyway, so it should work fine. Can you set the bitrate to odd values? 1953.125 bits per second is what we need (512 microseconds per bit).

I wouldn't recommend using it for anything really important, though. The ECU does sometimes suspend diagnostic data when it needs all its cycles for other things.

But it would be nice to use it to pull data that is otherwise very hard or impossible to get, like the ECU's computed load number or the ECU's reported ignition timing.

Posted: **Wed Feb 16, 2005 11:59 pm**

Yes, couldn't hurt to have a compact version of your scan tool implemented in this nice little product with an LCD and buttons.... odd bitrates should not be a problem at all with the PSoC.

I will have a fast ADC with a multiplexer for up to 8 rail-to-rail analog inputs for the important things.

Posted: **Thu Feb 17, 2005 12:02 am**

I've worked out the tables in SRAM (as flash tables would have a delay associated with reading them in realtime and SRAM tables are much quicker) on a silicon with more memory, so far so good. Here is the initialization code so far, what do you think about the scale/range of the tables V?

Code: Select all

unsigned char AirflowTrimTable[16*16]={ 	//256 bytes, 1 entire page of SRAM
//.5,	1,1.5,	2,2.5,	3,3.5,	4,4.5,	5,5.5,	6,6.5,	7,7.5,	8	<<--------kRPM
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=34psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=32psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=30psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=28psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=26psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=24psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=22psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=20psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=18psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=16psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=14psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=12psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=10psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=8psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=6psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	};	//MAP=4psia
//.5,	1,1.5,	2,2.5,	3,3.5,	4,4.5,	5,5.5,	6,6.5,	7,7.5,	8	<<--------kRPM
unsigned char TimingTrimTable[16*16]={  	//256 bytes, 1 entire page of SRAM
//.5,	1,1.5,	2,2.5,	3,3.5,	4,4.5,	5,5.5,	6,6.5,	7,7.5,	8	<<--------kRPM
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=34psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=32psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=30psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=28psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=26psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=24psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=22psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=20psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=18psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=16psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=14psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=12psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=10psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=8psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,		//MAP=6psia
	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	0,	};	//MAP=4psia
//.5,	1,1.5,	2,2.5,	3,3.5,	4,4.5,	5,5.5,	6,6.5,	7,7.5,	8	<<--------kRPM
//---------------------------------------------------------------------------------
unsigned char BoostSolenoidPwmTable[8*8]={	 	//64 bytes, 1/4 a page of SRAM
// 1,	2,	3,	4,	5,	6,	7,	8	<<--------kRPM
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=100% (WOT)
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=90%
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=75%
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=60%
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=45%
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=30%
	0,	0,	0,	0,	0,	0,	0,	0,		//TPS=15%
	0,	0,	0,	0,	0,	0,	0,	0,	};	//TPS=0% (idle)
// 1,	2,	3,	4,	5,	6,	7,	8	<<--------kRPM
unsigned char TPS_Reading=0;
unsigned char MAF_Reading=0;
unsigned char MAP_Reading=0;
unsigned char COOL_Reading=0;
unsigned char Tach_Reading=0;
unsigned char IGN_Delay=0;
unsigned char NumCylinders=4;	//default of 4-cylinder since that's what me Scooby is - used to calc RPM
BOOL OneTachPulsePerSpark=1; 	//set to 0 for revolution tach pulses, set to 1 for spark tach pulses - button toggled

I've got more code written but the majority of it so far is modular functions I've written previously for LCD control and custom data->string conversions.

(different tabs here... the tables looked better in the PSoC Designer IDE)

Posted: **Thu Feb 17, 2005 12:36 am**

Just some comments/notes I've been keeping in the project file... any corrections or suggestions are welcome.

Code: Select all

/*	------Notes------
WILL WANT TO UTILIZE A CRYSTAL FOR PRECISE TIMING (P1_0, P1_1, external crystal global setting)
Table 1 - RPM vs MAP, contains AIRFLOW TRIMS, 16x16
Table 2 - RPM vs MAP, contains TIMING RETARD TRIMS 16x16 (to compensate for faked low-engine load ECU resultant timing advance)
Table 3 - RPM vs TPS, contains BOOST CONTROL SOLENOID DUTY CYCLE, 8x8

Table 4 - RPM vs MAP, contains VOLUMETRIC EFFICIENCY data?  maybe an overall scale factor after the table pulls

-----------------------------INPUTS------------------------------------------
VOLTAGE / ADC INPUTS:
	AIT = need to add an AIT sensor at some point
	TPS = 5V? signal from tps on tb / on ECU pin __.  
	MAF = 5V signal from stock MAF sensor / intercepted from MAF.
	MAP = 5V signal from stock boost control pressure exchange solenoid / from ECU pin __.  
	COOLANT TEMP = Should monitor/display this as well / from ECU pin __.

PULSE / DIGITAL INPUTS:
	RPM = 12V square wave / pulses from ECU pin __.  One pulse per (revolution or spark?)  Time with TMR_TACH
	IGN_1 = Ignition control line #1 / from ECU pin __.
	IGN_2 = Ignition control line #2 / from ECU pin __.

-----------------------------------------------------------------------------
-----------------------------OUTPUTS-----------------------------------------
VOLTAGE / DAC OUTPUTS:
	MAF_Scaled = Intercepted/scaled MAF signal / output to ECU pin __.

PULSE / DIGITAL OUTPUTS:
	IGN_1_Out = Intercepted/delayed ignition control line #1 / output to coilpack
	IGN_2_Out = Intercepted/delayed ignition control line #2 / output to coilpack
	BOOST_PWM = Boost solenoid duty cycle / PWM output / output to boost solenoid
*/

Posted: **Thu Feb 17, 2005 3:31 am**

And one more update... man I actually got to work on this for quite a bit today! I've gotten the preliminary pinout complete with some spare pins that could be either analog or digital I/O, and some features we haven't discussed yet have been conceptualized in this layout. Anyway, here's the pinout:

I've got the modules placed and advanced the code quite a bit too...

Posted: **Thu Feb 17, 2005 5:12 am**

jake15

i was thinking and apexi afc or what doug did with the pentiometer thing, but i'm not that good at wiring things we'll see how it goes, hopefully it will learn how to control them within a day or two. Vikash said earlier in this thread that the ECU will control injectors up to 20% larger, and i figured that 440 is just below the 20% so hopefully the ECU will learn

I had to put my 2 cents in here. If you don't have a wideband 02 to see what your doing with a S-AFC then what is the point? If you do decide to start tuning shit without monitoring it, your going to do more bad then good.

Posted: **Thu Feb 17, 2005 9:36 am**

One thing about speed-density flow measurement on a turbo charged engine...

I don't know if I'm missing something, but the RTD's (TC's too) I've seen have a response time on the order of seconds. Boost, and therefore intake air temp changes a lot faster than that. It seems like the engine will be running way rich (and then lean when coming off boost) until steady state is reached. A "couple" seconds of bogging like that would seem like a long time.

Obviously there is a way around this, but wouldn't it require something that could estimate air density based on boost pressure, turbo efficiency, intercooler effectiveness, ambient temp, etc.?

Posted: **Thu Feb 17, 2005 2:07 pm**

Well, I can easily add a setting to switch between reading a standard 1V O2 sensor and a wideband 5V O2 sensor, so one could use either. No problem. Basic tuning can be done without a wideband, however, it's not like it's impossible. There is a usable signal there its just not nearly as accurate as a wideband. You can still tell if you're running super rich or super lean and correct these extreme situations.

What has a response time on the order of seconds, now? Nothing I'm doing here will be too slow, I will see to that...

So I've decided the first real task I'm tackling (after getting the inputs available for display) is boost control. Vikash, I know you said I'd need a boost solenoid duty cycle table, but what about a simple closed loop control system that you set to a certain pressure limit and the duty cycle to the boost solenoid is adjusted in realtime to maintain that pressure...? I bet it'd regulate that very well, and eliminate one of the tables. I've already written a similar PWM tracking algorithm for controlling an electric motor in a golf cart, I bet the same thing would apply here...

Posted: **Thu Feb 17, 2005 6:22 pm**

Woah. Let me catch up:

Chris - Hmm... It is kind of convenient, but it seems wasteful to go all the way up to 8000 RPM when the redline is 6500 RPM. The last three columns of the table can't be used. I think it would be better to actually stop just short of the redline rather than past it. Like maybe 250 to 6250 RPM, in increments of 375 RPM (or 750 RPM in the boost control table). I dunno, what do you think?

I don't think you need Table 4 (the VE table). That information will be kind of baked into Table 1 (the airflow trim table). Right?

All the pinout information is here: http://www.graphics.cornell.edu/~v/ecupins/

The MAP signal will actually come directly from the MAP sensor. It may be good to also monitor the pressure exchange solenoid, though... The PES switches the sensor to measure atmospheric pressure instead of manifold pressure, so when the PES is active (and maybe for a very short time thereafter) it might be better to just use the last-known-good MAP reading than to use the actual reading.

If you don't do that, though, it shouldn't matter too much. The ECU usually samples atmospheric pressure when the manifold is pretty close to atmospheric pressure anyway, or when load is very low so a little hiccup in fueling wouldn't matter that much. Old Chrysler turbos used the same setup but the ECU actually computed fueling based on the MAP sensor, so if you paid attention you could hear the engine hiccup when the ECU sampled atmospheric pressure, and that was a production car.

The IGN_x_Out outputs are actually going to the ignitor, not the coil pack.

You're storing analog readings in chars... Are the ADCs only 8 bit? Or are chars bigger than 8 bits on this chip?

The pinouts look way cool. So this is a 28-pin DIP? That's awesome. I had expected something surface mount.

What do you plan for the oxygen sensor input?

You could do a closed-loop boost control system, but to do it right you would have to implement at least PD, if not PID. I guess you already did that with the golf cart motor thing. But even then I'd say you'd still need a table indicating desired boost pressure as a function of throttle position. After all, you don't want to force the turbo to make full boost through a partially closed throttle plate, right? That would cause all kinds of badness. All in all, it seems like just having a table of duty cycles is simpler and just as powerful. But that's just my take on it.

A narrowband oxygen sensor can't tell the difference between "super rich" or "just kinda rich." It really isn't sufficient for tuning on-boost fuel mixtures by itself. However, with this thing we're developing here, we have a little more. Knowing the MAF transfer function and knowing the new and old injector flow rates might allow you to do some AFR tuning just based on the math.

I'll post the transfer functions in another post.

J-MoNeY - You're absolutely right that to do any kind of tuning properly you do need good instrumentation, like a wideband oxygen sensor and/or an EGT monitor.

hoolhooker - What do RTD and TC stand for? Are you talking about temperature sensors? They do make thermistors with much faster response times. Also keep in mind that air is flowing very fast over the probe, so circumstances are much more favorable than the typical "in still air" measurement. But, yes, you will end up running rich for a short period when boost starts. It's a phenomenon exhibited by most speed density supercharged engines, including OEM ones. It typically isn't so bad that the engine bogs down though.

I know GM does make two versions of their IAT sensors. One is identical to the coolant temperature sensor, and is used on naturally aspirated cars. The other has an open brass cage and an exposed sensing element, and is used on forced induction cars.

You could predict temperature like you say, but I don't think that's very practical. The biggest unknown is intercooler efficiency. I mean, what if the intercooler gets dirty? Or if you sit at a traffic light and get heat soaked? Or if it's raining and the intercooler gets cooled off some by the rain?

Posted: **Thu Feb 17, 2005 7:50 pm**

Transfer functions:

Manifold pressure is easy. MAP in mmHg in terms of V in volts:

Code: Select all

MAP = 400*V-280

Airflow and coolant temperature are table lookups. Here is the MAF lookup table. It is indexed in units of 5/256 of a volt and the values are in units of 1/256 of a gram per second (so they're 16-bit values):

Code: Select all

/* MAF signal conversion table, indexed by units of 5/256 V, each bit is 1/256 g/s */
unsigned int MAFConversion[256]={
    28,   22,   22,   25,   31,   39,   49,   59,
    68,   76,   85,   96,  110,  129,  151,  174,
   195,  212,  228,  242,  258,  277,  297,  318,
   338,  356,  373,  389,  405,  422,  440,  461,
   485,  513,  544,  576,  606,  633,  660,  688,
   721,  760,  801,  842,  878,  907,  931,  953,
   979, 1010, 1046, 1085, 1126, 1167, 1207, 1246,
  1283, 1319, 1355, 1395, 1440, 1492, 1550, 1610,
  1668, 1723, 1777, 1831, 1889, 1952, 2020, 2090,
  2159, 2227, 2294, 2362, 2432, 2505, 2576, 2641,
  2695, 2736, 2772, 2817, 2881, 2972, 3078, 3182,
  3268, 3324, 3367, 3415, 3491, 3608, 3750, 3893,
  4015, 4099, 4161, 4223, 4308, 4432, 4582, 4739,
  4882, 4997, 5093, 5184, 5283, 5401, 5531, 5660,
  5779, 5879, 5968, 6057, 6158, 6278, 6413, 6554,
  6692, 6822, 6947, 7076, 7214, 7367, 7530, 7697,
  7862, 8019, 8172, 8324, 8479, 8640, 8808, 8979,
  9152, 9327, 9504, 9686, 9874,10069,10268,10465,
 10654,10833,11005,11177,11356,11545,11741,11939,
 12132,12318,12502,12694,12901,13129,13372,13620,
 13864,14097,14323,14552,14790,15043,15306,15572,
 15833,16084,16331,16579,16836,17107,17388,17675,
 17962,18246,18527,18808,19090,19375,19665,19959,
 20258,20563,20872,21182,21492,21800,22108,22417,
 22731,23051,23378,23712,24052,24399,24749,25100,
 25448,25791,26134,26479,26831,27193,27560,27924,
 28278,28618,28955,29304,29680,30093,30537,31000,
 31472,31942,32408,32866,33315,33753,34183,34608,
 35032,35458,35882,36301,36711,37111,37512,37930,
 38377,38863,39375,39890,40391,40862,41311,41753,
 42200,42663,43136,43612,44082,44540,44989,45433,
 45878,46328,46789,47265,47761,48282,48833,49420};

Coolant temperature is also indexed in units of 5/256 of a volt, and the values are in degrees Fahrenheit:

Code: Select all

/* coolant temperature conversion table, indexed by units of 5/256 V, values in deg F */
signed int CLTConversion[256]={
 401,387,372,360,345,331,318,304,291,284,277,270,264,257,250,243, 
 237,234,230,226,223,219,216,212,208,205,203,199,198,194,192,189, 
 187,185,183,181,180,178,176,174,172,171,169,167,165,163,162,160, 
 158,156,154,153,153,151,149,147,147,145,144,144,142,140,140,138, 
 138,136,135,135,133,131,131,129,129,127,127,126,126,124,124,122, 
 122,120,120,118,118,117,117,115,115,113,113,111,111,109,109,108, 
 108,106,106,104,104,102,102,100,100, 99, 99, 97, 97, 97, 95, 95, 
  95, 93, 93, 93, 91, 90, 90, 88, 88, 86, 86, 84, 84, 84, 82, 82,
  82, 81, 81, 79, 79, 79, 77, 77, 77, 75, 75, 73, 73, 73, 72, 72,
  72, 70, 70, 68, 68, 68, 66, 66, 66, 64, 64, 63, 63, 61, 61, 59,
  59, 57, 57, 55, 55, 55, 54, 54, 54, 52, 52, 50, 50, 50, 48, 48,
  48, 46, 46, 45, 45, 43, 43, 41, 41, 39, 39, 37, 37, 37, 36, 36,
  36, 34, 34, 32, 32, 30, 30, 28, 28, 27, 27, 25, 25, 23, 23, 21,
  21, 19, 18, 18, 16, 14, 14, 12, 12, 10,  9,  9,  7,  5,  5,  3,
   3,  1,  0  -2, -4, -6, -8, -9, -9,-11,-13,-15,-17,-18,-20,-22,

 -24,-27,-31,-33,-36,-40,-42,-45,-47,-47,-47,-47,-47,-47,-47,-47};

If you wanted to store the temperatures more efficiently they could be encoded as 8-bit values a la MegaSquirt -- they add 40 degrees and then clamp the values at 0 to 255. This allows it to cover temperatures from -40 to 215 degrees.

For measuring MAP and coolant temperature, it would be ideal to take the 5-volt reference from the ECU's MAP sensor power supply pin (assuming this chip allows you to use a Vref for the ADCs that's separate from the power supply). That's because both those sensors' values are only accurate in terms of the ECU's reference voltage.

The MAF sensor uses its own inbuilt 5-volt reference so for that one it shouldn't matter where you get the reference as long as it's reliable.

Posted: **Thu Feb 17, 2005 8:09 pm**

vrg3 wrote: J-MoNeY - You're absolutely right that to do any kind of tuning properly you do need good instrumentation, like a wideband oxygen sensor and/or an EGT monitor.

Actually, I have heard bad things about EGT's. As far as I know, the EGT's only measure the temperature of the exhaust after the turbo. A couple of factors could play a roll in this reading being accurate. 1) Extreme hot or cold days are going to play a roll in the temperature to which the EGT reads, and 2) If you are driving your car really hard, the EGT doesn't know this from your car leaning out. All they give as a guess to what the actual air/fuel mixture is. Kind of like hooking an A/F gauge up to a regular 02. The only way to actually monitor the thing your changing is by an 02. Please spend the cash on one. It's well worth the investment when modding cars.

Posted: **Thu Feb 17, 2005 9:58 pm**

You're completely right about the limitations of EGT monitoring.

I didn't mean to imply that an EGT gauge is all you need to tune. I would say that ideally you'd monitor AFR, EGT, knock activity, and torque, and frequently read the spark plugs. After all, the reason AFR is important is that it affects the others, right?

Posted: **Thu Feb 17, 2005 10:42 pm**

Thanks for all the info V - hmm...

I'll respond to a few things now and when I've got more time I'll respond to more... this is great.

This is an 8-bit microprocessor... I can indeed store 16-bit values in tables if necessary but I would of course see if I could store everything as 8-bit as that is when this thing works at its absolute fastest. I'll just have to see what I can do while implementing various things.

The faster ADCs are 8-bit and the absolute fastest is a successive-approximation register type ADC with 6 bits. There are variable resolutions up to 14 bit I believe but the sample rates go way down. Not sure what other bottlenecks that might produce but it is also a possibility. I think it'd be best to start with everything 8-bit and see if an acceptable resolution is present in all relevant functionality.

I always start with the 28-pin DIP package but it is available in a wide variety of them, from 8-pin to 48-pin and all kinds of surface mount packages like SSOP and TQFP and MLF. Since I'd be hand-building these units for the board though I'll probaly stick with the 28-DIPs, unless we need an insane amount of digital I/O (which is exactly what the 44 and 48 pin packages are for)...

The RPM range seemed convenient and although we wouldn't initially use it, wouldn't it be useful to have control up that high? I mean, isn't someone on here running 7500 RPM? Or would the extra data points have that much effect on tuning with the expanded range?

And I thought so too about the VE table. I just remembered in one of your posts you mentioned I might need something like that so it was in the notes. It's gone now. Woohoo!

The O2 sensor, I can adjust a PGA's gain to compensate for the 1V signal or the 5V signal depending on which type of sensor is selected. That way, they will both be a 5V rail-to-rail signal which is what the PSoC does best with. I figure some tuning functionality will be available with a standard narrowband o2 sensor with this chip. A wideband would just make it much better.

More to come later when I've got more time... lol

Posted: **Thu Feb 17, 2005 11:03 pm**

Well, I think you could store the MAF transfer function with only 8-bit resolution, but it might be worth the extra cycles and effort to keep them 16-bit. The stock ECU has an 8-bit processor as well, but it does use this table. Actually, it only uses every fourth value of the MAF table (three out of four of the numbers above are from my own interpolation); it has a 64-element lookup table.

What are the sample rates like for the higher resolution ADCs? I really think that at a bare minimum the MAF signal needs to be sampled at 10-bit resolution, since that's the resolution the ECU samples it at. Stuff in cars happens very slowly in computing terms, so a low sample rate should be okay... Consider that even at redline you have fewer than 110 rotations per second.

Yeah, the thing I like about DIP is that you can use nice cheap plentiful perfboard.

Nobody is running more than 6500 RPM on the stock ECU; the ECU cuts fuel to prevent you from exceeding redline. While it could be useful to run beyond 6500 RPM on some motors, it can't be reasonably done with the stock ECU.

You might as well just always configure the PGA to sample the oxygen sensor signal with a unit-gain amplifier. Even sampling at 6-bit resolution using only one fifth of the scale is plenty for a narrowband sensor anyway. And, it'll help identify faults in the oxygen sensor's wiring (which our ECUs seem to respond very badly to, without even throwing trouble codes).

Posted: **Fri Feb 18, 2005 1:18 am**

Makes sense to me. I've noted the updates in the code, and will work on it more when I've got time. It's looking pretty good though, I didn't realize things happened that slowly in cars; never actually did the math but you're right. Should have no problem whatsoever with this thing then.

Hmm - I can sample the O2 sensor from one of the limited (and currently unused) SC analog inputs on port 2 to read the O2 voltage, which opens up a full 5V input but one would still be required there for the wideband sensor anyway so - might as well sample it at the same resolution as the rest of the readings. I will do everything in 10-bit resolution for now and see how that works out. The PSoC is relatively good at handling pairs of bytes as long as it doesn't have to do any floating-point math on anything. That really slows it down....

[shameless plug]
Hey V - you interested in this microcontroller? I wrote a book coupled with a kit of parts, with full explanations and source code... http://psoc.chrispaiano.com in case you want to look at the website. The kit becomes a programming socket and test platform and is quite useful.
[/shameless plug]

side note - when I have a prototype of this chip working correctly, I will offer kits and assembled units for sale on that site. Upgrades will be very inexpensive, you'll just be purchasing a new programmed chip to replace the old one.

Posted: **Fri Feb 18, 2005 1:45 am**

when yall are done here you should post some cn's in plain english of what your trying to do.

Posted: **Fri Feb 18, 2005 3:10 am**

Heh... I will write a book explaining everything in detail, when we get to that point. But basically I'm putting together an inexpensive product that will be a full piggyback tuning system, full capabilities on-board with an LCD and buttons but can also be tuned via laptop eventually. It will also double as a miniature scan tool, able to pull the same data you can get from the current VRG scan tool.

You'll be able to adjust a 16x16 table of airflow signal trims and a 16x16 table of ignition timing trims (tables have RPM and MAP axes) to adjust for oversize injectors with the stock ECU. Also an 8x8 table of boost solenoid duty cycles which will allow the user to discretely control boost based on RPM vs throttle with the stock boost control system.

Shift light is a no-brainer, settable shift light will be included.

Even has selectable realtime digital gauge display (and peak hold) of any input used (MAP, MAF, O2, TPS, coolant temp, etc).

All sorts of possibilities and features can and will be implemented in this product... feel free to add to it, you'll only be making it better.

Posted: **Fri Feb 18, 2005 4:16 am**

Woah, I had no idea you were involved in marketing these microcontrollers. Neato. I'll have to read through the site. Do you offer special discounts for Legacy Central members?

I'm a little confused... Is OmniSoC basically a bootloader for the PSoC? Or is it just the program for the four toy demos?

For a narrowband oxygen sensor, many factory ECUs (at least back in the day) actually just sample it with a comparator and a digital input. It really doesn't say much other than "rich" or "lean" anyway.

But it's still not clear to me what you're using the oxygen sensor signal for... Aside from just displaying it.

You should add in a feature to log all the parameters out the RS232 interface too. That'd be useful, I think.

Posted: **Fri Feb 18, 2005 5:41 am**

Just another comment on the high rpm limit. The stock heads really start losing efficiency around 5000 rpm.....so unless you really have someone doing some real heavy mods, I don't see any need to go above what the ECU's redline is.

Posted: **Fri Feb 18, 2005 5:41 am**

Of course there will be a discount for Legacy Central members. Legacy Central members get 20% off the tuner kits or assembled units, and 5% off the rest of the items. Vikash is getting a free one for coughing up all this information

I will sell just programmed chips with schematics for those of you who want to do everything yourself, these will only be probably $15-$20 (also will be the way upgrades are done). Complete kits (programmed chip, socket, perf board, wire, schematic, other components, removable terminal block, headers, buttons, LEDs, LCD, etc) will most likely fall in the $60-$70 range, and completely assembled units ready to go will probably be around $100-$120 or so. These are all overestimates, but even so this will be an inexpensive unit for the capabilities it provides. And yes those will be the prices before the discount.

I actually just worked out a signal sampler that has a large circular FIFO buffer in RAM and a button that captures the buffer to flash memory and continually repeats the captured signal to a DAC. It's so we can look at how clean or dirty the car supply voltage is without having to drag the 'scope out there. It can easily be adapted to log data, and once the laptop interface is done thats no problem. Good idea.

The o2 signal for now is just so you can look at it or display it. For now. It will eventually be used for something I'm sure.

I can do the comparator as well, but it would only be beneficial if I were to try and implement a closed-loop system for the narrowband o2 sensor. Might as well leave it as an ADC since theres plenty of processor time to spare and read a voltage, then the wideband is nothing extra.

Oh, and OmniSoC is the name of the book / kit / project that encompasses the PSoC test platform and the 4 sample applications it transmutes between.

Josh - good point about the stock heads, too - yes there is little reason to go beyond 6500 rpm for this project.

Posted: **Fri Feb 18, 2005 5:46 am**

Oh and - custom chips will be available as well, with different RPM and pressure ranges, for those of you who would like to use it with your high-revving overboosted Subaru racing application. For probably an extra $10 or so to modify the code to your specifications - it shouldn't be too much trouble at all.

Posted: **Fri Feb 18, 2005 6:16 am**

Vikash - in your MAF conversion table, you say the 256 different values are in units of 1/256 gram per second. does this mean the values in the table must be divided by 256 to get the measurement in grams per second? Or what were you envisioning?

Looks to me like I read an 8-bit value coming in from the ADC (a number 0-255 representing a voltage of 0-5V) and just index it directly to that table to pull the corresponding MAF measurement to display.

legacycentral bbs

T-leg Piggyback ECU R&D