Rods are what slide into the jets. They are tapered, so that when they are pulled up, more fuel goes in (richens up the mixture) and when they are pushed down, they let less fuel in (leans it out.) The rods are usually on a piston that is pulled down by vacuum. Less vacuum (more load) means more fuel. More vacuum (idle/cruise conditions) means less fuel.

 

I like it :yesnod: :yesnod: I've been doing the same thing, but totally in manual mode. I have a spread sheet for Edelbrock carbs and all the combinations of jet and rod that I've been using with the AF meter.

 

Ken,
This sounds really great. I think the rod question is related to Holleys which do not have rods and Q-jets do. I assume this will work with all carbs?
Ed

 

Very nice initiative, Ken, but I have to ask: shouldn't you build the prototype and test it BEFORE starting to sell the idea on the forum? :confused:

You know that a stock-type O2 sensor is a switching device, so how will you obtain semi-accurate data w/o a wide-band? I'm not trying to rain on your parade but it seems you'll need a wideband sensor to get any meaningful data. People have been working on DIY kits for this and maybe you could integrate your programming skills with some of their hardware development.

I sold my Trans-Am so haven't kept up with FI-related technology lately. Has something changed technology-wise to bring the cost down? $200 is pretty darn cheap!

thanks,

 

That is very cool and a great idea.

 

Hence once again, the title of the post - is there any interest in this system? If not, I wasn't going to bother developing it. Obviously, there is some interest. I spent last night drawing up the schematics (I had them in my head, just hadn't put them on paper/computer yet.) I already have 95% of the parts, I just need to sit down and prototype it on a breadboard. Once it's tested and working, I'll draw up some PCB's and see if I can make a prototype production piece also.

The stock type is non-linear, but most people who work with a WBO2 refer to it as a "switching" type, although it does have a degree of linearity that can be measured to it in the rich and lean areas. Notice that there are only two bars representing the whole stoich range (.25v to .75v!) rather than 7 or 8 that you find on most 10-LED AFR meters. Also take note that there's no AFR associated with the voltage. I didn't want to mislead anyone into thinking there was an exact AFR associated with a voltage. It does however, give you an idea of how rich or how lean the motor is running. It's not perfect, but it works and helps keep the price in the range of a hobbyist tuner.

The nice thing is, I CAN easily adapt this to use a Wide-Band O2 sensor setup and read accurate air fuel ratios! It would only really require the WBO2 sensor and circuitry - the DIY version would work perfectly. (Although, that jacks the price up another $200 or so for the WBO2 sensor setup.)

BTW, you're not raining on my parade at all. I'm glad you brought these questions up. It's nice to see someone else who knows what I'm talking about with the sensors!

Well, not really. Mostly it's just some ideas that have never been put together that I came up with. Simpler components, etc. I've seen too many complex designs; the idea behind this one was to be cheap as well as simple. Have you seen WinALDL? The hardware is only $5 and the software is free - I originated the concept or the fuel mapping. I had someone ask me about a year ago if I could do the same thing for carbureted cars and I blew the idea off until Aaron told me he wanted to put oxygen sensors on his car ('74) and AFR meters.

Knowing as well as you do that the commercially available meters are linear and the sensor isn't, I went on a quest to make a non-linear meter.. then came to the conclusion that it would be just as easy to make a simple interface on the computer that could plot out rich/lean/stoich on a grid so you could see it, rather than try to watch an AFR meter, tach, and vacuum gauge while you drive around.

Keep in mind - $200 is including a brand spanking new MAP sensor and heated O2 sensor! I prefer to use a heated because it keeps the temperature constant - any variance in temperature changes the linearity of the stock type O2 sensor. The further away it is from the engine, the cooler it is. This keeps it a little more consistent.

If someone has a WBO2 sensor for me to calibrate the stock-type (heated) sensor against, I could probably extrapolate some semi-close air fuel ratios, at least good enough for the home-tuner.

 

Of course! How you tune your carburetor is up to you - this is merely a display system that shows you where you're running rich or lean. It's up to you to figure out the specifics of changing your carburetor for optimum performance.

Aaron is running a Holley on his '74, and I'm running a Q-jet on my '73. I'm also running the Mallory Unilite ignition and Aaron still has conventional points, so it'll get a bit of a test right at home.

 

Killer idea. What kind of data logging capabilities could you include in the software? I think that would be valuable. Also, what sampling rate are you using?

 

I second that statement!
Logged or collected data is a very important feature!
I too think this is a killer idea, and the best thing since sliced bread for us "old technology" carbureted guys.


[Modified by Smokehouse69, 6:27 PM 12/30/2002]

 

Well well well, thats a heck of an idea.
Personally I think the map itself is about as usefull as a door stop for tuning my carb. (because I have no idea what it means, and if I can figure out the map, how does that relate to my carb :crazy: )

BUT it does form a perfect base to build upon.
What you really need to do it to put up a graphic of the carb under test ( be it holley, or Q-jet) and like you said show what and how much to change the jets, rods, air bleeds etc.

I also believe that the map is too static, transitions are important in carb tuning and therefore there needs to be a way to tune the more dynamic parts of the carb, like the vacuum secondaries, accelerator pumps etc.

As far as connecting to the 'points' side of the distributor, not on my car, it has a MSD distributor, you need to be able to read the tach output...

I really feel most controll software is underdesigned ( even some of mine :eek: ) and with a little more design it can be made truely helpfull. Rather than be just an expensive gauge.

Keith


[Modified by 427V8, 8:05 PM 12/30/2002]

 

:confused:

That'll have to be in a more advanced version. This is just the basic/beta version that will at least tell you what's going on somewhat. I certainily won't rule that out but right now the program is just in it's infancy.

I wholeheartedly agree! Although I'm not sure *how* to read those transitions - it's not like you can put a sensor on each little circuit within the carburetor, unfortunately. However, this is why I incorporated the instantaneous AF ratio meter - so you could at least "watch" those things to some degree. Any sugestions??

What I *have* been considering is putting in a graph function so you can watch an X-Y plot of each of the three inputs against time. You'd be able to see even more that way, but it would take up quite a bit of space.

As for logging, it can be done but I've still got a bit to learn in order to do it.

This is the kind of feedback I need. I think a few of my local C3 buddies have MSD; hopefully I'll be able to test it out on their cars.

And this program too, is in it's beginning stages. This is something I whipped up while learning Visual Basic on my own. :eek:

 

Well, the A-to-D converter I'm using samples at 1Khz I believe. with three inputs to sample.. so roughly 333 samples per second..? Although the parallel port doesn't read that fast. I'll probably make a speed up/slow down slider or something so you can change it to your desire/laptop.

 

I would be very intrested, but would I beable to tune my dual's, or is there another better way?

 

Ken,

I've been thinking about this some more. Would there be any value in trying to duplicate the INT and/or BLM functions to represent some type of "average" reading, or is this what you were planning? I think that would make the data more meaningful. BTW, I am familiar with Winaldl but never used it (started with Winbin and never looked back). I had a lot of fun tuning and burning.

If I were you I'd think about what you'd have to do to possibly incorporate a TPS type of function sometime in the future (even if it was discrete data ex. by a series of small hall effect switches or similar). That might make it easier for people to figure out where to make changes.

There's obviously interest and I'd probably stand in line for one too. Good luck! :cheers:

 

I'd be interested

 

count me in!!!
tom :jester

 

Actually, that's what the grid is essentially representing - the INT/BLM type stuff. Sure, I can make it to where it's latest, or averaged, or the last 10 averaged. What would you prefer? Keep in mind INT/BLM's are for fuel injection and will be harder to implement on a carburetor. (Particularly a 4bbl!)

WinBin is a program for changing parameters in a chip's BIN file; WinALDL is the program that reads the data that is output on the factory ALDL connector (hence the name.) The two compliment each other and are not competing products. In fact, there IS no competing product for WinALDL.

If I was going to do it, I'd probably build some sort of universal bracket and use a standard TPS. Not only is it a common part that is cheap/easy to pick up, but it can easily be bolted to a simple metal bracket. The trick of course, would be making it "universal" for all carburetors.

The program is just a display for approximate air fuel ratios mapped out over RPM and vacuum (load.) How you tune your carburetors is up to you. (For now, at least.)

 

Hey you responded before I could fix my nice guy remark :bb
It didn't sound so bad when I was typing it...

Well I do have some ideas about how to capture the data and process it.
I've been writing signal processing and analysis software for about 15 years and if nothing else have ideas :smash:
I cant say I invented these ideas, they just kinda forced themselveds onto me over the years.

0. Seperate Data and code
1. sample as fast as you can.
2 sample as accurately as you can
3, save everything.
4 process the data as late as possible ( lazy evaluation )
5. assume the user is an idiot and don't confuse them with the details
6. the right way of presenting the data and the almost right way is as different as lightining and a lighting bug ( apoligies to Mark Twain )


Those are general ideas a more specific one is that all the data needs to be kept together, I'd make a class that held one set of data ( time, temp, o2, airflow, tps, rpm, etc) and then just start sampleing and creating those objects as fast as you can, all held of course in a containner of some sort, prolly a linked list. then you could have visiters that could cruse the list and massage the data however you want.

the best part is it becomes very easy to add functionality since all the data is in one spot. VB may gag a bit on creating objects fast enough but I doubt it.
Can you use a memory mapped file in VB? It make things fast in VC :D


LOL probably more that you wanted, sorry I get excited about software

 

I suspect that some sort of steady-state might be reached :confused: depending on how coarse each cell was. You'd probably have to build a test unit to see. My comment was aimed towards the concept of using an integrator to update a slow-changing BLM-type number, but just to keep track of sensor output. Even when bouncing around on each side of stoich. the average tended to move in the right direction.

Doh! (Toldja I never used it!) I used another software for data collection but there was always good comments about WinALDL on the thirdgen board.


Yeah - I was just thinking that some sort of TPS information would make it easier to figure out which carb circuit needed attention. Maybe that part of the system could be an "option" with a software switch if the user decided to implement a TPS sensor.

:cheers:

 

carburated engines are slow to respond to changes in the fuel curve. on a dyno you must stay at a certain rpm for for quite a while for the carb to stabilize. fuel injection engines responds instantly. :chevy