RBob

iTrader: (1)

The NB is slower then a WB. The response time/curve of a NB also varies between the rich excursion vs the lean excursion. The curve varies according to the exhaust temperature. Many masks have correction tables for this. And a host of other things. Can get the simulation close enough to keep the ECM happy, but is it close enough to keep the engine happy? While the ECM is in closed loop it forces the AFR to oscillate making the WB not too useful.

Open loop tuning is easy. The commanded AFR is a known, there are no corrections being made that oscillates the WB reading. And without the closed loop corrections the tuner doesn't need to take them into account when changing the VE/MAF table(s). To stay in open loop just set the closed loop temperature enable term at a high value.

Then compare the commanded AFR with the WB reported AFR and make a correction to the VE/MAF table at that point. Of course need to do some additional checks for a stable MAP/TPS/MAF signal, not in DFCO or enleanment. PE is just a different commanded AFR so that works. Don't do anything until the coolant is at normal temperature. Simple stuff.

I feel the same about displays, not needed. The bar graph one that I used was really nice, but what did it tell me?

I hit the gas and it dipped lean, then rich. Ok, tune the AE with that information. What was the delta TPS% and the delta MAP terms for the AE fuel? Without that you can't tune the AE tables.

Having those two terms along with the WB reported AFR in the data stream allowed me to get the AE dead on.

Same with PE mode tuning. Wack the gas and watch the display, nope, I can't even watch the display and keep track of what the RPM was and what the AFR was at that point, and keep an eye on the track, and shift, and. . . see the problem. Well, I may be able to do it driving the parts hauler

The WB's I use are a box sitting on the floor, or up under the dash that get data logged. The tuning software takes under a minute to run and produces new VE tables. It reads the current tables, reads the data log, produces a matrix of correction terms, applies them and outputs new tables.

RBob.

Cobra289

Please RBob can you correct me if I am wrong?

Here is my understanding from some comments made by several people.

Looking to the point of data logging will be an interesting thing.

The integration in the tuning software is not a big deal according to Mark but we need to agree where to mapping the input and output.

Witch one will be, the spare TPS2 or the spare MAP2?
Do we have problems with earth?

OK DIY
I found that we need to do something our self.

We need to change our BIN (code)
Or
We need to patch our code to read the WB input and give to the Tuning Software (TunerPro in my case) the information so that we can see the output.

I am not so fast guys, but this is what you are telling us when you say data logging?

So guys start to read the sticky “patch method demo” we need it!

It goes about other item (RPM limit vs. Speed limit) but we need to understand how it works to apply a new patch to our BIN.

Oh man! Oh man! here we are with a lot of DIY.
I hope that we get some help to achieve this goal.

I am lucky, the last week I made the decision to change for a new BIN, I have started to work with the APYP ($6E) and found that there is a source that assembles It is made by “86Red4+3”

This information was found at:
https://www.thirdgen.org/techbb2/sho...hreadid=105227

You can find BIN files already patched at:
http://www.eecis.udel.edu/~davis/z28/WB_hacs/

Regards,
Cobra289

Ken73

I see, makes sense now. However, I would think that a delay could be put in to mimic these operations in the AVR that Craig is going to use?

Quote:

Open loop tuning is easy. The commanded AFR is a known, there are no corrections being made that oscillates the WB reading. And without the closed loop corrections the tuner doesn't need to take them into account when changing the VE/MAF table(s). To stay in open loop just set the closed loop temperature enable term at a high value.

Then compare the commanded AFR with the WB reported AFR and make a correction to the VE/MAF table at that point. Of course need to do some additional checks for a stable MAP/TPS/MAF signal, not in DFCO or enleanment. PE is just a different commanded AFR so that works. Don't do anything until the coolant is at normal temperature. Simple stuff.

Simple to you, sure! Keep in mind there are people out there who are "tuning dummies" like me! Believe it or not, I've done so little tuning it's not even funny; mostly because I saw the ridiculous processes involved and decided to come up with better hardware/software solutions.

Quote:

I feel the same about displays, not needed. The bar graph one that I used was really nice, but what did it tell me?

I hit the gas and it dipped lean, then rich. Ok, tune the AE with that information. What was the delta TPS% and the delta MAP terms for the AE fuel? Without that you can't tune the AE tables.

Having those two terms along with the WB reported AFR in the data stream allowed me to get the AE dead on.

Same with PE mode tuning. Wack the gas and watch the display, nope, I can't even watch the display and keep track of what the RPM was and what the AFR was at that point, and keep an eye on the track, and shift, and. . . see the problem. Well, I may be able to do it driving the parts hauler

See, this is the kinda stuff I don't know yet. This is BIG help for me!

Quote:

The WB's I use are a box sitting on the floor, or up under the dash that get data logged. The tuning software takes under a minute to run and produces new VE tables. It reads the current tables, reads the data log, produces a matrix of correction terms, applies them and outputs new tables.

Any chance you could work with Mark to incorporate your tuning software into TunerPro?

RBob

iTrader: (1)

NB simulation:
Yes, a 1.5Hz low pass with a table lookup (WB to simulated NB voltage) can be done. Just adds development time.

I don't see why not. Would be a good way to go as I do DOS utilites where most folks aren't sure what a command line is.

RBob.

stuckatcuse

Here are my votes!!

NB simulator:

Absolutely.

Display:

Absolutely.

These two things can work together and prove their usefullness.
My arguement is that:

A. I don't want to have to lug out my laptop every time I want to see A/F ratios. The display can be modular, thats fine.

B. Slow response times? These uControllers run at MHz speeds, they're response time will not be an issue. If it's done by driving op amps into saturation, it will be in real time!!!! (Or at least close to the speed of light, or the slew rate of the amp (V/usec.) I am fairly sure all the cpu cares about is xcounts anyway.

With a display and simulated output people wont have to drill into their exhaust, crawl under/ jack up their car and swap sensors or weld a new bung on for another sensor. This will make the device much more appealing. Additionally, once the car is tuned, having a display will be one more measure to let you know something isn't right if say, something isn't right. It will pay for itself the first time it tells you something is wrong before you blow your engine. So if feature creep is classified as something that will a. make the device more inconvenient than it needs to be, and b. prevent a visual warning that something could be very wrong with your vehicle, then displays and sim outputs are feature creep. These two things will add maybe, maybe, maybe $30 to the price of the unit.


C. Please do not make the final boards surface mount. (For R&D purposes it's fine) Most people do not have rework stations and this will KILL the DIY ness. Most people have trouble with thru hole stuff, nevermind surface mount.

Just my $.02

I'll take a look at the spec sheets. Good job digging for them

Sean

MTPFI-MAF

Thank you, a few google Searches and then digging through the ones that had no useful info and wa laa a good Spec sheet.

any ways I think that I would like a NB simulator and a led Display if it does what it is supposed to do correctly, and dosent take this project into the non DIY level.

I was thinking on the NB simulator and it would be nice to beable to just remove the old NB Sensor and put the WB sensor in it's place.

and With a display it would also let me dissconnect the Unit from my car and take it to another car and use it a a WB02 Meter, Via:and spare sensor that is hooked to a tailpipe adapter, and a Power adapter. Now IMO that is functionallity. But you know what they say about Opinions

Yes I agree that the display is feature creep but they would be But some feature creep is Useful to the design if done correctly and we agree that it is needed.
any one else have opinions on the type of plugs we should use for Power & Ground, Data Transfer ECT. I still like the Data option for the RJ11/45

Edit: Or maybe if it is possiable to do just a Guage Output to a Guage Like Dynojet commander's 270 degree sweep electric gauage or Innovate's Anolog guage so that way there is a port that will send the data to their guage and if people want the gauge they buy it form Dyno jet and hook it up the the Connection on the WB02 if they don't well, the port is just a port.

here is a link to the DynoJet WB Guages http://www.widebandcommander.com/artwork.htm
Just my .02

JP86SS

iTrader: (1)

Re-iterated from earlier post:
--------------------------------------------------------------------------
I don't know if trying to do the "low ball" approach to the whole thing is really needed. It may just cause re-design to implement new "basic" functions that WILL be considered as necessity as the program progresses (and surely there will be something!) Using the controller and doing firmware would be great progression from earlier design and allow for limited feature creep now but expandable as needed. Adding ports now will same design later.
------------------------------------------------------------------------------

I'm with ya there.
The added ports would make the unit portability better and can still be kept to the minimum.


Looks like the general consensus (sp?) is coming together.

Just need to clarify if that's "General Disarray" or "Captain Chaos"
Couldn't help myself

RBob

iTrader: (1)

Before everyone gets cozy with removing the one-wire NB sensor and bolting a Bosch WB in place, it won't work.

A WB sensor will not operate at the manifold temperature levels that the NB is subject to.

In particular a Bosch WB needs to be a good 3 feet down stream of the exhaust ports. Even further is better.

As for a display I'll take a step back then hopefully at least one forward. I am against the inclusion of a display with the 'box'. If folks would like a remote display I do not have a problem with that.

It just should not be included with the basic box.

RBob.

MTPFI-MAF

I agree it should be remote.

since we can't just put the WB sensor where the NB Sensor was is there a purpose of keeping the Simulated NB signal. What are the ups and downs of having and not having a Simulated NB signal.

JP86SS

iTrader: (1)

Does this mean no matter what, a second bung must be placed 3 feet down?
I was under the impression it could be placed in a stock location
(aproximitly 1 foot down ) I,m not sure of the teps there.
I also agree remote display is better
(ported so variations could exist)

Synapsis

From looking at data on the internet about NB and the LSU4, the operating ranges seem to be about the same (775-875F). And if this isn't the case, can't you heatsink it?

Ken73

What a coincidence.. mine already is! Of course, I don't have an F-body..

Still, I'd like that *option* since it shouldn't be too hard to incorporate (?)

Quote:

As for a display I'll take a step back then hopefully at least one forward. I am against the inclusion of a display with the 'box'. If folks would like a remote display I do not have a problem with that.

It just should not be included with the basic box.

Agreed. Jonas has a nice little unit, Bill and I have a nice little unit, I'm sure Craig could come up with something desireable; you could probably scale it down to 0-1v (linear) and use it with an Autometer 20-LED gauge... I think a display should be left off the main unit. There's already a ton of options out there; make it versatile by allowing the end user to choose what display he wants.

LB87FORMULA

iTrader: (3)

This is a response to an earlier post by Craig,

I own a small engineering company with a complete surface mount and thru-hole assembly line. Most of my business is DOD or short run prototypes for local business. I could assemble the SMT parts on boards while the user would only have to solder the thru hole parts. This would reduce cost, space, increase reliabilty, and still give the person some soldering experience...

Yes I can solder, but my 3rdgen still doesn't idle smooth.

JP84Z430HP

Exactly. Maybe even develop a couple different displays that are made for it, but after the unit is ready.

That's interesting about the location of the WB sensor. The last Honda I looked at, I thought it was just about a foot away from the head..... I can look tomorrow, my friend has one! Not doubting, just remembering what I've seen....

I still fail to see how a faster reacting sensor is gonna make the ECM not work properly.... Maybe I need to dig deeper into the source code to see it!

Thanks to Craig for initiating this, and for all that are contributing, I'm actually learning a bit from this post even!

stuckatcuse

Is this b/c you think the sensor will get too hot? Anyone with a factory heated o2 is safe if that's the case. Mine is just before my cat at least 2.5 to 3 feet away from the exaust ports. I bet it would work even closer. If the sensor is only $30 i'd try it. So much easier than welding another bung on there.

Also: That wideband commander gauge looks great! I'd love to have that thing in my car with a DIY controller!

Grumpy

If you investigate the Bosch sensor you'll see that it can be operated at too high of temp.. In the case of the Innovative, it will actually set a code if it gets too hot.

And there are a host of factors that kick into play about sensor life, dependent on where downstream it's mounted. Searching for Gar, and particulate matter at DIY-EFI should gather the related material.

JP84Z430HP

Now that I think of it, I think the Honda's use the NTK sensor.... Different beast.....?

32V_DOHC

I personally have never needed a WB and a NB at the same time. The NB gets in the way and muddies the waters. Tuning should be done in open loop. I don't see any added value to a NB simulator.

I also think any display should be divorced.

My ideal new DIY-WB would be one that functioned the same as my old DIY-WB only used the greatly less expensive sensor. In fact my ideal situation would be plans to mod the existing WB controller to drive the less expensive sensor. Cost is what keeps this out of everyones hands. A sensor driver is all that is needed.

I will help in anyway that I can.

John

MrBill

Because its a feedback control loop system. If the response time of ANY element in the loop changes significantly then this time must be compensated for somewhere else or the loop will become unstable.

Of course this shouldn't be an issue running in open loop.

jamesbob02

Pardon my ignorance, but what is the significance of "surface mount" (what does it mean, and why do we not want it that way?)

Also, as long as we can get the WB data into the ALDL stream somehow, I could care less about the NB simulation or putting it in the stock location. No problem welding in the bung here, I just want everything to be able to be read together in TunerPro.

And honestly, I do not see the point of a modular display if it changes too fast and you can't compare it to other readings.

At the very least, let's be sure that it's an external option for those of you who want it, as long as it wont drive up the cost.

Oh, and whoever said we shouldnt try to go lowball on this, I disagree. That is basically the point of this, isn't it? Feature creep is a disease....let's just keep what 90% of us will want, and anything else optional, so long as it doesnt affect the cost.

Craig Moates

This is all good dialogue. Sounds like we're coming down toward what is needed. To revise earlier commentary:

1) Basic control box
2) 0-5v output for ECM / auxiliary logging
3) Possibly 0-1v NB output if the dynamic kinks can be worked out
4) Possibly connection header for external display (LED)

Actually, one thing I like is something like Ken said, and that is for general display go to something like the AutoMeter LED sweep gauge. It's sort of the 'industry standard', and many people already have one. If not, it's like $50. It gives a good visual indication, looks great, and is available to anyone. You could hook it up to one of the outputs (NB Sim or other output) and set the relative mapping of gauge reading as function of AFR in the firmware of the control box. Could even make up a transparent decal with the AFR numbers printed on it and stick it on the face of the gauge.

But that's all bells & whistles. The heart of this thing is the proper control of the wideband sensor itself, and rendering of an accurate signal to represent true AFR.

Surface mount is doable, just takes a good bit more soldering skill. If folks want to learn how to do it, I think that could be a good thing. Be prepared for some tedious work, but again it's doable.

stuckatcuse

Surface mount is the method of mounting the components to the PC board. The components have solder tabs which mount to the surface of the board. The components are also typically half the size of thru-hole components or smaller.

In a thru hole setup, the components sit on the top of the board, but the leads stick thru and are soldered to pads on the back and cut off. They are about 2x-3x-larger than surface mount stuff, so they may about 33% more. The catch is, that unless you have an expensive rework station (for soldering surface-mount stuff) or have years of soldering experience, soldering on surface mount stuff is a disaster. Want an example? Open up your computer case and look at how the components are mounted. Imagine soldering those on by hand????? What a PITA??????? Impossible for the novice diy-er. Thru hole stuff may be 20 years old, but it still works great!

I guess we could do a cost analysis at the end. It depends on how many components there are (read, PITA index) and how much the cost will be reduced by using the SM stuff.


Also, the display clould be made to update at any rate the design calls for. If the sensor updates at x times per second, then the display can update at x/y times per second. If we had the display update at the fastest possible rate, then we wouldn't be able to see anything, but 18.88 or 4-5 leds on at the same time!! Remember a lightbulb turns on and off at 60 times/sec.

Check this out...
http://www.plxdevices.com/M-Series-C..._M-300Demo.wmv
I don't think it's changing too fast in the open loop mode. If that thing suddenly shot up to 18.xx then I'd let off the throttle in a drag race. Remember this thing won't oscilate like a narrowband sensor will. If you had a supercharger and knock retard disabled, that could save your engine right there.

MrBill

I have to respectfully disagree with this statement. What you're seeing with the stock setup (bouncing back and forth between rich and lean) is not *really* an oscillation per say. What's happening is the nature of ALL feedback control loops. The O2 sensor generates the "error" signal for the loop which the ECM uses to compensate the A/F mixture. The "error" signal in ANY loop will always swing back and forth around the "zero error" point (which in this case is the stoich A/F ratio). Typically in a closed-loop system the error signal is very very small when the loop is working properly (locked), but that's not the case here. Our "error" signal (output of the O2 sensor) is very large. Anyway, the amount of the "swing" around zero error is based (for the most part) on the ECM itself, not the sensor.

JoBy

I don't think a too fast NB simulation is a problem at all.

If you have a control loop with a slow sensor then the regulator must also be slow to keep the system stable. Using a faster sensor will make the life easier for the regulator. It would still be stable. When using a sensor that is slower than what the regulator is tuned for, that is when you get into trouble.


This is what 'my' display looks like during a WOT run. It is very fast but still easy to read.

http://w1.605.telia.com/~u60513000/temp/joby_vette.mpg

( I might add the I was just starting to tune it )

stuckatcuse

I don't want to start an arguement or beat a dead horse so I'll just clarify what I meant. Any control system (unless critically damped with a static input) will osciallate. I should have said the WB won't oscilate to it's rails. I just meant that the wb output will oscilate over a NARROW range near stoich. Whereas a narrowband output will oscilate to it's rails, yielding the dancing light display. I just wanted to remind everyone that a WB display won't bounce from 8.0 to 20.0 AFR. The display will stay around 14.xx for closed loop and 12.xx (depending on tuning of course) for open, and that it will be very usefull and easy to read. I think it has already been decided that we won't have one anyway (just the header for one). Maybe we can inculde the design for one in the diy but make it completely optional! That way the laptop tuners don't have to buy the header or components. That would be cool with me!

Wouldn't the key just be keeping the cross counts close to what the stock sensor would provide? I am not to sure about this... I need to think about it more. Is that a wideband display? It seems to be bouncing a lot.... Is it just a narrow range of AFRs?

JoBy

A slow sensor adds time lag to the system. With time lag the regulator must be slower to keep the system from oscilating.

As the ECM increases fuel until it detects rich, and then reduces fuel to make it lean, it will oscilate. With a faster sensor the cross counts will probably increase, but I don't see that as a problem. It only indicates that the ECM spends more time near lambda 1.0.

I don't see why more cross counts would be bad.

stuckatcuse

Cool sounds good to me. I was just thinking that maybe if the system couldn't keep up or was too fast, then it could go unstable? Like I said, I haven't thought about the NB Sim much, so don't listen to me about this!

I'll shut up now.

Synapsis

If there's a delay loop in the ECM code calibrated to read a slow sensor, it might require changes to read a faster sensor. For instance, if the NB simulator swings back and forth too fast.. it might always read on the lean side when the ECM samples the sensor.

I haven't verified that such a loop exists. I haven't looked at a hac in at least a year.

JP86SS

iTrader: (1)

It sounds to me like the PID control of the S-term integrator will need to be worked on to stabilize the loop due to the faster feedback readings.
This could be a huge step in control if it can be pulled off.

Z69

FYI Derivative is the Rate of change of x.
If the Derivative factor in the loop has much of any value at all. Then a faster signal will require that term at a minimum to be changed. I've seen this problem in none automotive apps. It causes the loop output value to swing faster and with greater amplitude. Not a good thing if your trying to maintain a tank level.
Most of the time there isn't a D value though. I'd suspect it isn't used for the closed loop algo.

JoBy

No need to make a problem out of it if it isn't a problem.

If there is a delay in the code to wait for a slow sensor, fine. If you wait with a fast sensor it does not hurt ... You get the same reading after the wait.



Think of it like this ...

You have a switch connected to a lamp thru a ten second time delay.

The lamp is off.
You close your eyes.
Flip the switch.
Wait for 15 seconds and then you open your eyes and see that the lamp is on.

Now remove the time delay from the circuit.

The lamp is off.
You close your eyes.
Flip the switch.
Wait for 15 seconds and then you open your eyes and see that the lamp is on.

As a matter of fact you did not notice any change at all, because you had your eyes closed waiting for the lamp to be lit ...

JP86SS

iTrader: (1)

I didn't really look yet, but are there any response times that can be compared between the two types? Not based on the ECM making the change for the response but true sensor frequency response of 0-90% or the like.
That would shed some light on just how far off the concept is in actuality and then we can plan a stratagy to utilize it.

Edit:
It does state the response time of >100 ms on the Bosch unit, Still looking for OEM sensor info.

JP84Z430HP

Now that I think of this, the sensor is gonna be a few feet downstream (I think that sounds the way it's supposed to be with the Bosch WB), so, from the time the ECM makes the correction, to the time the sensor reads it will be a bit delayed. Even if it's not, the ECM reads the O2 in clock cycles, correct? Evevn if the sensor responds quicker, the ECM is only gonna read it so fast....

Am I way off base here?

funstick

well the o2 sensor switching speed does change with engine RPM. ill save some file from the scope at work and show you what im talking about.

MrBill

No arguing here man! I guess I did misinterpret the original statement....sorry 'bout that.

You guys are on it

JP86SS

iTrader: (1)

Not to get too far off the topic BUT it seems to be getting relevant.
I have worked with PID controls for a while now and don't understand why the WB signal could not be used for running corrections just like the OEM sensor.
I'm sure somewhere the code could be altered to read 5V output rather than 0-1V ??
If not, then zero and span the WB to a 0-1V signal and possibly adjust the AFR calculations in code to match ???
I'm nowhere near that deep into the code to know if this is possible.
The prospect of tuning AND running with the WB in control sound like the ulitimate goal. This WB controller is just the start of that possible reality.
There should be a way to tune the ECM to allow correct operation with it.
I did a small writeup a while back on PIDs that might spark someone who has intimate knowledge of the code to comment on if this concept is valid or impossible due to limitations I'm unaware of. This much control may just be overkill for the application ???
https://www.thirdgen.org/techbb2/sho...&highlight=pid

If this is too far off the baseline, feel free to move it to another thread.
Jp

gregger2k

I've been away for a while but THIS IS A TREAT!! Cool stuff!!

I think we need to start discussing a toolset for this project. www.avrfreaks.net is a great AVR resource to what is available.
A C compiler would make the source more understandable, extensable, and maintainable. The AVR micros handle C great and a Mega32 or greater has plenty of code space, RAM, I/O, and Analog to Didital inputs!

I have tried the open source AvrGCC compiler but it is not my favorite because it is harder to use than some of the other ones.
I currently like the CodeVision - it is easy to use and the author is great at updates and bugfixes.

Another neat tool to keep it modular would be a tiny RTOS. It is a little more work in the beginning but maintaining and extending the code would be easier in the long run. PR-RTX s one that I have been experimenting with and it is not to difficult to use or expensive. Neither products require royalties on developed code.

An AVR development board could speed up the development process. A couple inexpensive ones to look at are MegaAvr and AtmegaDev

Let's Go.....

Craig Moates

No!!!!! No fken way will I deal with C Compiler crap, especially on an AVR!!! I've been doing stuff in straight assembly and I'm OK with that. If someone else wants to do the firmware then fine. Otherwise count me out...

Then again, I haven't even taken the time to learn C. However, I don't look forward to the inefficiencies and difficulty tracking stuff down in terms of what's happening on individual clock cycles...

Mangus

Poor naive boy, that Craig. And with a potty mouth, too!

Just kidding.

MTPFI-MAF

Ok I don't know my way around source code yet so this is probally very hard but I was thinking about having a table that has a setting for the WB commanded AFR at different RPM vs. LV8 (or what ever would be more relivent) sorta like a timing table. So that way you could program different AFR's at different RPM's, LV8, TPS,ECT and such so that you would have the ability to give the engine exactly what it wants where it wants it. That would be a Great tunning tool

This would kinda be like intergrating Traxion AFRTuner

this would also intergrate with Marks and Craigs Auto Tuning that they Mark mentions in his TunerPro Progress

of course I work 3rd shift and just got home, so if this is complete ignorance just Slap me, I will understand.

stuckatcuse

I know with the motorola stuff if you are using a c complier you can just put asm{} tags in and write functions in straight assembly. Then you can call them from normal c code. It makes things like looping much easier. Craig, you could just start a c file with asm{ and end it with } !!! Then you'd be using a c compiler. Motorola also has a real-time simulator. If 4 K is enough code space and 12 pins are enough, we could get the motorola chips for less than $2 or $3 for a 4 channel 8 bit a/d, pwm output timers etc. (The HC08QY4) The only limitation I see is a small amout of ram 128. Plus codewarrior development studio is free if the code size is under 4K. Oh wait no serial stuff though. If you guys really want avr lets go for it. I'm up for learning something new. Should we start to decide on a uController?

MTPFI-MAF

Ok I have found that the LSU4.2 can be ordered from www.1stvwparts.com for $30.00 dollars using part #VW#021-906-262-B. This is VW# for the LSU4 sensor Bosch #0 258 007 057 or 0 258 007 058 the two different Bosch # are the same sensor with different length leads.


The connector is VW part number 1JO-973-733

The wire terminals are part numbers 000-797-133, 000-797-133A, and 000-797-225 {3 required}


This info was obtianed form Bowling & Grippo's megasquirt2 website at: http://www.megasquirt2.com/PWC/

Now $30.00 is a Killer Price.

Craig Moates

Sorry, didn't mean to overreact on the C -vs- ASM thing. Certainly if anyone is willing/able to start chewing on source code for the AVRs from a different angle, I'm fully supportive. Like Mark says and knows, I'm stuck in the dark ages. Surprising I'm not doing everyting in straight binary.

As you know there are 10 different kinds of people.
Those that love binary and those that don't...

Craig Moates

The Mega8535 is a pretty good choice if we go with AVR. It has the following:

8k program space
512 bytes SRAM
512 bytes EEPROM
32 I/O lines
3 external interrupts
TWI/I2C (for external serial eeprom storage)
1 USART/UART
4 PWM outputs
8 10-bit A/D converters/inputs
16MHz max speed

Availability is in 44-pin PLCC or TQFP, with 40-pin DIP available as well.

Unit price is in the sub-$5 range for quantity

Here's a PDF (about 2.5mb):
http://www.moates.net/zips/mega8535.pdf

I'm open to other ideas for sure, but this one seems to hit the mark, even if a little bit overkill.

jamesbob02

With average soldering skills, I'm definitely opposed to surface mounting. Somebody else would probably have to do it for me.

What are the chances of it being surface-mount?

Craig Moates

It can likely be done in non-surface mount. But it'll be a little more expensive probably and a lot bigger physically.

jamesbob02

I don't want to rock the boat...I'll go along with what the majority wants, but that would definitely be my preference.

stuckatcuse

Craig- are there cheap development boards availiable for this unit? (or plans to make a programmer/development board) readily available? Are there plans or a particular unit that you prefer?

Thanks,

Sean

The_Punisher454

I've been lurking these boards for quite a while, but this subject has forced me to respond. I have been messing with atmel AVR's and narrowband sensors for a while now, using standard parallel interface LCD displays.

The AVR is without a doubt the best choice for this type of project. As far as the ASM-vs-C thing its no issue for me I just use the fast and easy "FASTAVR basic compiler" but thats a personal choice(based on simplicity and super fast develpment time).

The important thing for me is that you use a 40 pin dip AVR such as a Mega8535 (which is pin compatable with some larger AVR's) so that you can have future upgradability on the unused pins, without slowing development progress at the beginning.

As far as the simulating the slower response of a narrowband sensor it almost too easy to even warrant conversation, you just write the program so that you just change a single variable to adjust the number of times you run the filtering loop.

The display situation is also very easy to address. Just reserve one port on the AVR for display driving, and have different display routines depending on what type of display you connect to an 8-pin display header. With 8-pins you can drive anything from a simple LED array to an LCD with a bargraph and digital readout both.

I would also strongly suggest that you use lookup tables with a Linear Interpolation routine. I did this on a narrowband setup and it worked great, and made it easy to re-calibrate later by tweaking the table ( I used the LCD display and a small keypad so that it was field tunable without any external hardware).

Also start with a 16Mhz setup so that you have alot more headroom left over for more detailed filtering and other types of software growth in the future.

A simple board with expansion headers making all AVR ports available would be where I'd start. The hard part will be driving the LSU, the display and interface stuff is trivial.


The Punisher

funstick

Actually with a proper interface to send the 0-5v signal to something like an unused TPS input all youd need ont he software side is a 2d lookup table ( the WB 02 is not linear its more parabolic in shape ) to help it derive the actual afr from a Vout on the control box.

As for the software side. it should even be difficult. its just gonna involve rewriting the o2 sensor pid controls to stop modulating the AFR up and down and to read it directly. idealy youd add a 3d table with a look up of rpm vs map vs afr

anyways thats enough of my thinking outloud.