Staged extra Injector control + other goodies design. Input wanted

[Joryn]

I step away for a few hours and holy moly I'm loving the ideas that are coming out of this thread thus far, kudos to Frank for putting some thought into the user interface (haven't really thought that far ahead yet).

couple comments to try and answer what's been posted:

Brian/Frank -> love to help you guys learn the pics if you're interested. LIke i had mentioned earlier I'm pretty rusty and fortunately the programming of these things is a breeze...given the right equipment. My brother-in-law actually maeks low voltage programmers (basically cost about 4 bucks to build) which work well with the PIC's. So that's what I'll be using. I might be able to get him to build acouple extra to send to you guys if you're interested.

As for the PW tables I do like the idea but trying to setup a table manually like that might take a while. Depending of course on how many points you want in the table. The chips I'm looking at have 1024bytes of EEPROM which is likely where I'll store the data tables for various things. I figure about 256 bytes/table should give us more then enough resolution for most things we are controlling. Course 256 points might be overkill for something like you're takling about but it's nice to have a Lot of adjustability hehe This is definitely something to look into more. I'm going to need to determine what resolution will be good for sensor inputs and other thigns as well. So input here would be great.

The ABS sensor idea I've actually thought about a bit. On a design project I was on last year we were thinking about having a gauge to monitor that for pretty similar purposes. Depending on how expensive to obtain and difficult to implement they are though, I'm not sure if we could practically use them here. It may have to come down to you feel the wheel's spinning? let off the gas alittle hehe. Can't let the computer do everything after all, that's just no fun

I'm eager to hear more ideas and hopefully see this project shape up a bit more over the next while. Wish me luck and keep the input and help coming. !

[Frank]

I dont think it would be all that intensive. You only need 4-6 pressure/pwm points. The rest can be extrapulated without problem. This is especially true if you use an injector. Of course I am just stuck in the thought of a simple Alky/Gas injection controller.


Frank

[Frank]

For this project, 8 bit A/D's will probably be good. This would give you +/- 128 increments. 2^8 is 256 and since the MSB is a sign bit in most cases (except automobiles), you have 128. So with either case, typical ranges are 0-5volts, so that gives you 39mV and 20mV respectively.

Sensor output is going to be more difficult because of PWM. You need good PWM control, so you have to have good frequency resolution and duty cycle resolution.


Frank

[Joryn]

Quote:

Originally Posted by Frank For this project, 8 bit A/D's will probably be good. This would give you +/- 128 increments. 2^8 is 256 and since the MSB is a sign bit in most cases (except automobiles), you have 128. So with either case, typical ranges are 0-5volts, so that gives you 39mV and 20mV respectively. Sensor output is going to be more difficult because of PWM. You need good PWM control, so you have to have good frequency resolution and duty cycle resolution. Frank

The number of PWM/Pressure points sounds good. I can probably code in some extrapolation without taking too much more processing time.

As for the A/D I was actually only going to be using 8 bits of the 10bit a/d anyways so that works well with my thinking. The majority of the EEPROM is going to be used for sensor tables. at 256 bit resolution from an 8 bit A/D that's 256 values we need stored in EEPROM. Unless we use a smaller value and extrapolate inbetween values. Total # of sensors I'm looking at inputting here is pretty high so this might be a required option. It's the main reason why I picked up a controller with a large eeprom onboard. Of course we could always get a secondary serial eeprom for more storage but I'm going to avoid that if i can.

Just to clarify, what did you mean by sensor output being difficult cuz of PWM? The sensors themselve's aren't pwm obviously so I wasn't sure what you meant here.

And the goal is still for a alky/fuel injection system. This overall system will hopefully have a lot more features built into it, but the intiial goal is to have a reliable secondary fuel system controller. Let's hope it works hehe.

[Aries_Turbo]

Quote:

Originally Posted by Joryn I step away for a few hours and holy moly I'm loving the ideas that are coming out of this thread thus far, kudos to Frank for putting some thought into the user interface (haven't really thought that far ahead yet). couple comments to try and answer what's been posted: Brian/Frank -> love to help you guys learn the pics if you're interested. LIke i had mentioned earlier I'm pretty rusty and fortunately the programming of these things is a breeze...given the right equipment. My brother-in-law actually maeks low voltage programmers (basically cost about 4 bucks to build) which work well with the PIC's. So that's what I'll be using. I might be able to get him to build acouple extra to send to you guys if you're interested. As for the PW tables I do like the idea but trying to setup a table manually like that might take a while. Depending of course on how many points you want in the table. The chips I'm looking at have 1024bytes of EEPROM which is likely where I'll store the data tables for various things. I figure about 256 bytes/table should give us more then enough resolution for most things we are controlling. Course 256 points might be overkill for something like you're takling about but it's nice to have a Lot of adjustability hehe This is definitely something to look into more. I'm going to need to determine what resolution will be good for sensor inputs and other thigns as well. So input here would be great. The ABS sensor idea I've actually thought about a bit. On a design project I was on last year we were thinking about having a gauge to monitor that for pretty similar purposes. Depending on how expensive to obtain and difficult to implement they are though, I'm not sure if we could practically use them here. It may have to come down to you feel the wheel's spinning? let off the gas alittle hehe. Can't let the computer do everything after all, that's just no fun I'm eager to hear more ideas and hopefully see this project shape up a bit more over the next while. Wish me luck and keep the input and help coming. !

Sure, I'll take a programmer (or at least the plans so I can build one). Lemme know what PIC's you are using so i can purchase a few myself. I have my freescale map sensors so i can incorporate them into the design. You know of a good place the offers a tutorial on PIC's? do the datasheets for each chip have the code listed out? thanks

Brian

[Joryn]

Quote:

Originally Posted by Aries_Turbo Sure, I'll take a programmer (or at least the plans so I can build one). Lemme know what PIC's you are using so i can purchase a few myself. I have my freescale map sensors so i can incorporate them into the design. You know of a good place the offers a tutorial on PIC's? do the datasheets for each chip have the code listed out? thanks Brian

I'll talk to my brother in-law about those programmers. I think he might actually end up marketing them as they are cheap to make and very useful when compared to the cheapest programmers that the actual companies offer. I'll let you know as soon as I can about that.

The pic's i'm using are the pic16f877A/pic16lf877a(both the same, one's a lower power version), I've also started looking into using an 18f2525 which has a higher EEPROM but smaller i/o pin count. I might end up going for the 18f4620 which is a 40 pin version with 1024eeprom. Microchip is actually really good for samples as well if you want to hit them up for a few of each of those. Ithink you can have as many as 3 each up to 3 different types for samples. 2 orders every 40 days though so make sure you make thsoe samples count.

As for programming them, the coding itself that I'll be using is straight C code. The microchip website has a developement suite that is available for free. the c compiler for that suite is obtainable, either you can pay for it...or you can be sneaky and find way's around that heh. I'll have to find a new copy myself I think so when I find where to get a good copy I'll let you know. So if you're familiar at all with basic C code you've already got a great start. trying to program in assembly is kinda a pain imo. but in some cases' thats all you've got.

HOpe the info helps, let me know if you need to know anything else

[Joryn]

Here's the url for the development software that microchip provides:

Microchip MPLab Page

and here's a direct link to the software:
MPLab IDE 7.11

[Frank]

For an alky/fuel injection system used for adding to your current fuel, there are only a few needed components in my honest opinion.
1. An input for measuring boost pressure. (A/D)
2. An A/F piggy back input (not really needed). (A/D)
3. A way to input the following settings
3a. System trigger by boost pressure
3b. Flow rating of the mister or injector, etc.
3c. What PW to use for a range of pressures
4. A output for a switch that turns on or off the pump. (Simple 1/0 Output)
5. A PWM output to control the "bleed off to tank" solenoid to control the pressure. (PWM Out that I mentioned... needs be high frequency resolution)
6. An input for rail pressure of the mister or alky. (A/D)
7. An input emergency 20% adder like the SDS. (Simple 1/0 input) If, for example, EGT's rise, I can press this button for a large fuel dump into the air stream.
8. Sets of outputs for LED indicators for like arming, etc. (Simple 1/0 ouput)


You dont store each actual value of the A/D into the EEPROM either (of course that may just be a misunderstanding between us). If you take your voltage range of say 5 volts, and you know its 8 bit, then that is 5/(2^8) which says for every machine unit increment, it is 19.5mV (also called the LSB - least significant bit). So if I have a a binary 00000001, that is 19.5mV (thats a 1 in decimal, so times the 19.5mV by the decimal number and you know have your real units). If you have a 10101010, that is 84 decimal, so times that by 19.5mV, and that is now 1.64volts.

Now for voltage to say fuel/alky rail pressure (if it is non linear. for linear relations ships, a simple y=ax+b can be used), you will have to build a table. However that wont need to be that big. You can interpolate/extrapulate. I would think you would need no more then 16 voltage to pressures... so that is about about 128bits. You would have a series of pressure bins that you put a voltage into.


Just some food for thought.



Frank

[Joryn]

Quote:

Originally Posted by Frank 1. An input for measuring boost pressure. (A/D) 2. An A/F piggy back input (not really needed). (A/D) 3. A way to input the following settings 3a. System trigger by boost pressure 3b. Flow rating of the mister or injector, etc. 3c. What PW to use for a range of pressures 4. A output for a switch that turns on or off the pump. (Simple 1/0 Output) 5. A PWM output to control the "bleed off to tank" solenoid to control the pressure. (PWM Out that I mentioned... needs be high frequency resolution) 6. An input for rail pressure of the mister or alky. (A/D) 7. An input emergency 20% adder like the SDS. (Simple 1/0 input) If, for example, EGT's rise, I can press this button for a large fuel dump into the air stream. 8. Sets of outputs for LED indicators for like arming, etc. (Simple 1/0 ouput)

Well this is a good list to have up. There's a number of items on there that I hadn't really thought of yet, and also a number of items missing that I think could/should be up there.

Here's the ones that I think might also be a good idea:
9. Input for Detonation sensor (A/D)
10. Input for EGT sensor (A/D?) - you mentioned this but didn't list an input for it
11. Output for controlling a boost control solenoid(PWM) - this is more of a nice option at this stage.
12. Input for TPS (A/D) - could use this to monitor for WOT and allow only certain operation unless car is at WOT.

That's just a few of them and they may not be all that useful. The Det sensor I think would be nice as part of the safety system I had talked about ages ago in this thread. The safety system is dependent on having control of the boost though. ie: sensors reading too lean, too high EGT, too much detonation, shut off boost. Similar to the fuel dump. Speaking of which anything more you can tell me about that? Does that sort of thing work when you're reaching thel imits of the fuel system? ie: can it dump more fuel when you've already maxed out flow rate/pressure? I like the idea as it's potentially an engine saver as much as the boost cutoff(little less slowing down though).

Fortunately Frank I know exactly what you're talkign about. I was using too much space in the EEPROM for A/D tables. There really isn't any reason to hae that much resolution. Using pools for voltages is perfectly acceptable. Having high resolution on some things like the A/F, detonation and EGT though might be a good idea.

From the looks of what I"m seeing for input's/outputs (assumign we put Everything so far onto it) we are looking at one heck of a microcontroller to handle this puppy heh. It might be a good idea to look at pin counts to see what we need. Scope out the datasheets for the aforementioned MCU's and see how many PWM outputs they have (most come with at least a couple built in hardware, although we can alwyas write a PWM output using a gpio) how many A/D's they have etc.

hehe...I must admit, all this micro talk has got me wanting to get into this thing hardcore. Keep it coming!

[Joryn]

Post 100!! heh, Anyways, I just noticed a bit more about what frank was talkign about for A/D tables

here's what I've done in the past. The value coming out of the A/D I took and used that as the address for the EEPROM. So for example Say we got a signal of 3.4V coming in from a sensor. on a 5V referenced 8 bit a/D thats AA in hex. Take that value and use it as the address for the eeprom where at AA you have the value 3.4V stored (or 34 or somethin that you can relate to).

The main reason I needed to use tables before was cuz of the non-linearity of the sensors that I was using. Specifically temp sensors and what not pretty much required an eeprom table. Something that has a very linear voltage/measurement response would not need it as much and could probably get away with calculations on the a/d value.

is this making any sense?? heh

[Frank]

hahahaha.

Now you know why VEMS has turned into nightmare... they couldnt say no to anything and dont feel like documenting. It is almost done though. Anyway, your project....

I dont think all of it is nessacry. You might as well build a Megasquirt with added features as a spin off. The key to success is simple. Let me expound upon this.

Detonation Sensor - Useless in this setup. You can't control timing (or I havent read enough of this thread). You can add more fuel/alky, but depending on your range, you probably cant add enough (aka lack of control margin) or add it fast enough. Timing is pretty instant. However Detonation is very important. My suggestion is to create a dual output OpAmp circuit that reads in the knock sensor, outputs a raw signal to the ECU for its purposes, and then outputs the other signal to a band-pass filter to pull out noise and use that in a resister/diode ladder attached to a bar LED display. The frequency to be used is simple. Run the output to a mic input on a computer. Use Audicty program from sourceforge.net that will give you a FFT of the audio signal. While you are viewing it, advance the timing at idle-1k rpms You will see the frequencies that increase. These are the ones that you want to pass thru in your filter. However after typing that and re reading my previous ideas... I had mentioned the emergency adder.

For actual fuel adder like alky/fuel as a secondary, some simple where you just keep the sensor inputs to a minimum keep your life simple. I think thats a beaten horse and its your idea. I will help in anyway that I can, so carry on with your ideas. I will help.


Frank

[Aries_Turbo]

ahhhhhh this is getting insane heheehhe. frank for the fuel pressure solenoid, its easier to use a boost referenced fpr... Use a 87 T1 regulator. Thats much easier.... plus I have a few around somewhere for me to use lol.

Brian

[Frank]

Quote:

Originally Posted by Joryn Post 100!! heh, Anyways, I just noticed a bit more about what frank was talkign about for A/D tables here's what I've done in the past. The value coming out of the A/D I took and used that as the address for the EEPROM. So for example Say we got a signal of 3.4V coming in from a sensor. on a 5V referenced 8 bit a/D thats AA in hex. Take that value and use it as the address for the eeprom where at AA you have the value 3.4V stored (or 34 or somethin that you can relate to). The main reason I needed to use tables before was cuz of the non-linearity of the sensors that I was using. Specifically temp sensors and what not pretty much required an eeprom table. Something that has a very linear voltage/measurement response would not need it as much and could probably get away with calculations on the a/d value. is this making any sense?? heh

Actually is not that simple in assembly... or not that I remember. I also now realize it is a voltage and pressure bin for sensor setup.

Using an example of 3.5volts, you will see a 0hB3. Since you have limited points in your EEPROM, you will have a bin at say 0hCC (4volts) and 0h9A (3volts) of which they represent, according to your sensor setup, a 9psi and 5psi respectively. Since you have to do simple interpolation, you do the following with the code.... you scan thru the voltage bin/array which is going to be around 15 bins at say start address 0h04, find the 2 bins/addresses that you fall between and then pull the voltage there which you find the address to be say 0h09 and 0h0A. You now know that you are on the 5 and 6 addresses in from the start. You then go to the pressure array/bin and look up the value that is at the 5 and 6 position from the start address of the pressure. You now have V1, V2, P1, and P2. They are your end points. They then determine your slope (which is m) and put it into the equation of y=mx where x is your measured voltage and y is the new pressure.


You gotta love Micros which use stuff like the C language.



Frank

[Frank]

Quote:

Originally Posted by Aries_Turbo ahhhhhh this is getting insane heheehhe. frank for the fuel pressure solenoid, its easier to use a boost referenced fpr... Use a 87 T1 regulator. Thats much easier.... plus I have a few around somewhere for me to use lol. Brian

Yeh but you still have to know what the pressure is to determine which PW signal to use to get to X pressure as stated by you all before as needed. Pressure sendors are simple, and then use a bleed of solenoid. Its cake also.


Frank

[Aries_Turbo]

yeah but thats one more output to build circuits for so just have a fp input.