The great $8D Idea List
 

Post ideas on whatever can be thought of to do with 730 ECM.

Come on all you $8D Lurkers out there...
Yes you!:eek:

Get in with suggestions, questions, there is a need to get this ball rolling again.
Without a good set of base requirements this will die or just fall back a bit. Much progress with code enhancements has been done by only a few. (You know who you are and there are many benificiaries who are thankful)
A few of my personal issues:
1.) I am still looking to incorporate an unsued (or used) output to turn on a light or LED using the knock flag to get an indicator. Make it usable with or without emmisions. May not be possible without losing a function but its something to shoot for.
(Maybe turn the output into a TPS switch, future nitrous?)
2.) I want my SHIFT LIGHT and TCC too!
Again it might be possible, might not.
3.) Add "tweakable" WB. Keep defined tables for common sensors and add one for the user to play with if scaling is not what is desired from preset outputs. (That's an easy one to deal with, I think)

What are some of the code things being done elswhere?
I don't get around as much as I used to so if you hear something that just sounds neat, post it.
More ideas promotes investigation for how to implement them.
Just need MORE people investigating little pieces of the puzzles.
There are allot of ideas for applications out there. Don't forget that with the NVSRAMM adder to the 730, a whole new world awaits. WB WOT fueling? Launch mode? Autotune???
I'm sure there are other items that have fallen by the wayside that can be brought back into the light now for another look.
Most may not get done, but some will. I'm optimistic.
That's still more than we have now :)


Just stirring the pot!

An auto tune function for VE would be great! Something similar to the thread on the Ultimate TBI code.

The WB logging is great (Thanks again, Z69!), but wouldn't it be nice to incorporate that into some WOT auto VE tuning as well?

The knock sensor/spark retard indicator light is a great idea, one I hadn't thought of.

IMO, far too much emphasis on the $8D has been put onto just the 700R4 equiped cars (Super_AUJP for example). As a manual tranny guy, I'd like to see a similar effort to something like AXYC (the last GM manual tranny BIN) if possible. It would really help us relative newbies to prom tuning get a reasonable performance oriented starting point.

As for other $8D ideas, Maybe a spark table auto tune? Where it drops the spark table values where ever knock or spark retard was detected as long as the BLMs are under 128?

Or maybe an output fron the ECM to be able to program and turn on a real shift light?

Or a programmable launch rev limiter? (would require some sort of switch to indicate when you wanted to use it)

Or a way to program in VSS signals for different rear ratios that would also correct the speedometer? (eliminate the need for a DD buffer box, for example)

Probably a lot better ideas out there, but I'm still trying to get my 383 SuperRam "tuned" good enoug to take it to the strip for the first time - I'm no where near as far advanced as a lot of the guys on here. But I'm willing to do some testing of whatever is developed!

Don't know if this can be done but I would like a setup for a 4l60E. Someday may put a puter trolled tranny in without using a second puter.

I once heard mention of using the knock sensor input as a "traction control" for launches with a manual switch to turn it on or off (knock sensor normal).

I'd love to see VSS correction for the dash too. I have gotten better at guessing my speed, but seems stupid that we can correct it for the ECM, but not for the dash.

Shift light ought to be there, it's in the code, I installed a bulb in my dash, just need to make ti work.

Finally, i'm sure with everyone, i'd love to see a useable WB input on the ECM. Logging is one thing, BLM & INT adjustments based on WB would RULE!

I will help however i'm needed.

Well commented hack and/or a COMPLETE xdf file with item comments for everything. That's a huge start. Then you can start removing things and/or adding to the code without much difficulty.

I believe the vette $8d has a computer control for traction and it also has a shift light. The traction is linked to the ABS -it has a sensor in the wheels that compares it to the vehicle speed.

That's an active traction control, *you* can put together a passive traction control that works almost as well. Both launch assist, and traction control can be implimented, with some work.

What happened to the SAUJP V4 thread? Maybe we should combine these and keep the interest going.

I didn't want to junk that one up.
this thread should be "Pie in the sky" stuff that could eventually be looked at or done if someone gets to it.

OK John TTT:D:D :D

Hardware mod idea: add a USB interface using FT2232C chip to allow faster aldl rates.

The rate is not really the base problem as I see it.
Getting the data faster will only give you more of the same numbers faster.
The loops only update the actual "holding" locations every so often so reading them multiple times does not give you what is desired. There have been some testing outputting smaller packets faster IIRC but I still believe the above to be true.
A way to transfer the actual used memory locations from the RAM locations to the transmit holders faster is key to it.
Then a faster comm could be implemented to take advantage of it.
I don't know if there is a way to put something like an indexer in the "fast loop" and transfer a data point out on each iteration.
That may work without using up or exceeeding the available time in that loop.
???
Am I on the right track there, or is there another way I'm not seeing?

Close, but what you actually described is how the old 160baud aldl works... :D The 'fast' loop runs at 160Hz, hence the 160 baud rate.

You can get to the stage of information overload. I've seen some 100 channel datalogging, at 100 frames a second, and it quickly gets overwhleming. 15-17 frames a sec., is fine, unless you really want or need to do oem level work. So far, it seems that for the novice, if you need more then 15 F/S, then a scope answers the question.

Now, an affordable, automotive laptop scope would be nice. Storage would be even better, 4 channel min........

That would indeed be nice! It only needs to store a 5 minute FIFO.
I'm sure Craig is already working on it (or its already done ) :)

There is USB hardware out there that is under $100 but it's no o-scope. I can see the scope for measuring injector on-time but everything else could be captured with some of the USB conditioned equipment out there.
Another alternative is National Instruments daq hardware. Ebay has good prices and they come with enough software to do datalogging... just not much processing.

A LabJack is cheap if you want to measure voltages and stuff quick enough, but honestly, knowing what the ECU is thinking is so much better. Some way to get a floating cursor on each table to see where the ECU is looking up from would make tuning 100x easier.

How about a 3d table for EGO target volts. Did that one get mentioned yet?

Programmable VSS acceleration rates for launch control (retard ignition, cut ignition (screw the cat)) (dVSS vs VSS table).

Soft rev limiters - maybe if VSS <= X, rev limit Y, for Z time after VSS >= X.

Can it POSSIBLY control ignition timing below 400 RPM?? Like set the base timing actually GREATER than the max desired cranking timing, then fire after the next REF pulse is recieved, rather than trying to anticipate timing at low speeds (difficult - low accuracy). It would be like calculating 80-90 degrees timing I think.

Here's a stupid idea that doesn't involve code - run two 730's with wideband control for each cylinder bank, and each one controls the respective bank. Signal sharing is easy, just have one ECU supply the 5V signals, and the other sampling signals and sharing grounds. Would only have to add another ECU connector with the correct wires connected. Sounds REALLY easy actually. Realtime programming would suck though. Would probably want to do just chips on that arrangement.

I don't know about 2 controllers but if there is enough bin space the needed code could be copied then made to run each bank separately. Of course the ECM needs to be fast enough but I think it can be done with the WBO2 proving a second O2 sensor can be added. The idea of logging and having dual O2's to control each bank is a great. I was asking about a da2-3 conversion because of some of this with concerns about split BLM's. The code is newer, has larger tables, and appears to be very similiar to $8d except for the Opti. I do not know the ECM differences but if the opti code could be replaced then the newer bins could be used. Grumpy mentioned something about a 2240 would be the direction but I never found any info on that. I am also stuck in the first gen stuff as I am reluctant to have to buy a new harness, etc. at this point in time for a limited amount of benefits. If the bin could be extended from a 256k format to a 512k format then there should be enough room to do just about anything. I am not a programmer but my thoughts were to have plug and play patches. Take the best code known say for spark advance and make a patch. Take the best VE and MAF code and make a patch, etc. I guess that they would have to be specific to the ECM's also. This would probably force a specific bin and maybe a build from scratch earmarking areas for specific code and then giving enough space for growth. This is way over my head and all I can do is test and help with the easy stuff like defining xdf's etc.

YES YES YES. WinALDL had a funtion built in where it would display where the engine was at (RPM x kPa) on the BLM grid. This made tuning very easy. It would also log the BLM to the cell where the engine was at during that period. This worked much better than a datalogger in my opinion.

A 3d table for O2 volts would be awesome. I think the 730 is lacking in that department. Heck, the 747 has more than the 730 in that respect.

4x channels = 4 bytes
15 fps * 4 bytes = 60bytes / second
4096 bytes / 60 bytes/second = 68 seconds

You can a make source code patch to store 60 seconds worth of 4ch data (raw data as the ECM sees it) in that 4kb nvram add on card. If you can live with 30 seconds of data, 30fps can be had. Or 15 seconds at 60fps... you get the idea.

Yes, you can set it trigger RPM to less then 400, but IMO, since your on the module it's all moot anyway.

Nope, the temp inputs use 2 switchable pull up resistors, so you need a sensor for each one. Or really shot the doodoo out of having any resolution.

It's a caddy ecm, it used a dual sensor distributor, and was SEFI.

Once ya'll spend some time with SEFI, you'll never go back to batch.

That any you'll find that alot of the problems you have been fighting disappear, and others with simple patches get cured.

Oh yeah, the temp signals would each need a sensor for each ECU. I actually have two (different) ecus on my car and knew that was needed, just forgot. Luckily, there was an extra spot for a CTS in the stock manifold right near the original, and I didn't need an IAT for the other ECU at the time. Do what you want for IAT I guess. Lately seems there's a few arguements about where to put it, so I'll stay out of it.

About the cranking timing, I mean change the ECU code to send 5V to the BYPASS even during cranking. Then control timing.

Look at an application where the MAT really is important, and how they run the code with it mounted there. All one has to do is look at the Syclones, and it becomes obvious, where to mount it, and the tables and code to use best use that information. Seems simple enough to follow the lead of what teams of engineers have developed for you.



There can be alot of electrical noise, voltage fluctuations, etc, etc, during cranking, that's why they use something as dumb as just the module. It also serves as a default ignition in case the processor dies.

Unless, you can come up with a real stronge arguement for having a need to change the crank timing, I just don't see the point.

BTW, during low voltage cranking the engine is can *back up* with too much timing, and actually try to start running backward during crank, that usually gets you a huge backfire. Again, a good case for the engine getting to a min speed before adding timing in. Some of your aftermarket systems have a crank 20d retard for that very reason.

No strong arguement on crank spark control, just a wish list thing. It just reduces any compromise vs temperature (assuming it works without errors). I didn't intend for it to be a constant value, but rather a crank timing vs temperature. Saves a few burnt fingers if you'd like to "play with it" or "give it what it likes" or simply calibrate it to optimum.

I like using a TMAP sensor. That has to be in the manifold. Inlet ducting air temperature means practically nothing to the engine, other than maybe a better way to predict *Ambient* temp better on a restart, for whatever reason ambient temperature may be needed. Maybe it's a way to get a cheaper plastic sensor in there.

Those crank retard boxes are meant to be used on a locked distributor as far as I know. I know a guy that builds flatheads, and runs a fixed timing distributor (no mechanical or vacuum advance), and needs it for cranking, along with a bajillion racers that run a locked distributor (fewer parts to fail or stick). I personally haven't seen anyone run cranking too far ATDC for any reason.

From what I've read, those 20d retard setups have you set the max advance you want as the static value.
They pull 20d for start and then go to full or ramped timing depending on how much money you spent.
The ignition boxes that have the start retard are useful
on the big cam/big cube motors that like 20d static but the starters like to protest that setting.


Keep the wish list coming.

Multi stage Soft rev limiter.

A 730 lockers setup would be very useful.
But the little 4k add on board might be sufficient but time consuming to use.

My idea for the $8D code is in the methodology. In order to implement the code changes it would be best to start with source code. Source code that can be assembled back to a bin. Properly done with labels, no hard coded addresses, will be a great asset.

This will provide many benefits. Changes can be made right to the actual source and re-assembled. The same source code can be used for both stick and automatic tranny cars. No more 'if this BCC here are the locations, for this BCC use these locations.'

Won't need to worry about actual patch files. Or having the end user apply them. A bin is provided and the end user does the tuning. Placing new calibration data after the current data will allow for minimal changes to ECU files. Will only need to add the new stuff.

Then document the changes and how to use them. My thought has always been to let the end user do the tuning. Provide the tools and the DIY part takes care of itself. Other tools can be a VE table update program (such as the VePhD and VeMaster stuff). Can use either the BLMs for closed loop tuning, or use the WB input for those running open loop.

As for enhancements (some have already been mentioned): soft touch rev limiter, 2 stage rev limiter, option bit to use the closed throttle SA table (I find that table to be troublesome), greatly expanded VE tables, new RPM term that is RPM / 33 (or around that), then VE tables to 7 or 8 thousand RPM, remove the 800 RPM idle limiter, N2O control, WB input with multiple tables for data logging, option bit selection for which WB table to use, activate an output when in PE mode, etc.

RBob.

WOW - that all sounds great!

Just to make sure it isn't passed over - the idea of a display (that is logged and re-playable) for the VE, spark, and possibly accell adders) that show where the ECU is reading would be great as well. That's probably a data logging software issue though.

As for the ULTIMATE TPI code ideas, I really like these:

- Soft rev limiters (at least one, two would be better for launch control as well)
- Expanded VE and spark tables (one big table for each would be great!)
- WB input selections for datalogging (already done for some BBCs - Thanks, Scott!)
- RPM-only software selectable shift light output signal
- VE table updating auto tune
- Spark table updating auto tune (if knock and BLM <= 128, retard setting)
- Auto tune software should NOT auto smooth tables, but have that as an optional change to the tables
- Same code for auto and TPI cars sounds great, but suggested settings for each would be better
- RBob's selectable use of the closed throttle SA table
- NOS control
- VSS corrections for gear changes with an output for the speedo/cruis modules (eliminate need for DD box)
- WB input for auto tune VE option
- Knock sensor and spark retard indicator light outputs is a great idea

And the real biggie...

SEFI (granted it would require harness mods, but if it were an option in the code that would be great!!)

That a big enough Wish List? I'm available for any testing, etc., but have never done any assembly coding (a fair bit of "C", but that was several years ago)...

OK here is my real list but don't know if I will ever get to it:

1. Computer control for a tranny. That should take care of shift, etc if you are an automatic guy. Sorry I guess I am showing my age.
2. Dual O2 setup. If it controls BLM's fine at least give me easy datalogging.
3. SFI with a hitch. This should work for GEN I motors with off the shelf GM parts. I know Grumpy was mentioning the Caddy stuff. The 96-98 trucks and burbs have sequential with puter trolled trannys. The motors are Gen-I where they use a plastic timing cover that has a crank-pos sensor built in. I believe that they have a timing wheel that will fit any crank setup for it. You can buy a harness and computer and make this work right now.

Back to the LT1 code. It has SFI -even code for individual cylinder adjustment, puter troll, and can accomidate a MAP or MAF by checking a single box. Nice large tables. Now if this can work with a crank pos sensor minus the Opti how much further do we need to look for a single do all bin that is still OBDI?

A VEsmoother written in C wouldn't be bad.
Just make sure to make the table size user definable or at least easy to change....
I haven't looked at VEmaster to see if it would be a good reference.

I haven't sat down and figured a good way to code it but I've done smoothing and have some ideas on how to improve it. The first thing is to weight each "cell" with how many good samples it's recieved. Those cell's don't move as much and instead the cells surrounding it will with less samples will move more. Heck, you could even lock the really learned area's. Then have it so that the VE doesn't go down as map increases, etc. Have some rules to the smoothing to make it worth while.

Any way of adding additional outputs? Just digital on/off would suffice.
Cascade or multiplexing the hardware to use external additions?

What is a VEsmoother?.

Here's one versions txt file excerp
A goggle on smoothtools might turn it up.

Written in C would allow it to actually edit the bin like Traxions little program. Basically do away with the constraints of VEmaster.

After talking with Joseph Georger, the creator of VE master he has released VE master under GPL. VE master is written in C++ and I have posted the code on Craig Moates site if your interested.

If anyone is interested in writing a VE smoother in C++ VEmaster is a great starting point, it already is fully functional, and would be great with a few features added.

No need for it to be written in C, or even C++. I can directly edit bin files in VB and LabView.

8D Lockers
 

All of this U-TBI discussion has really made me wonder... what is it that makes Lockers possible on TBI, but not on 8D? Is there something fundamentally different, or has it just not been developed yet?

High on my list for 8D (or other P4 apps) is higher speed logging of ALL the RAM contents. Sounds like Lockers is the way to go.

todd

Re: 8D Lockers
 

Most folks get by with just the normal 8192 ALDL rate of the P4s. Few folks need or appreciate being able to look at all the RAM locations.

Yes, a full Blown P4 Lockers would beat anything out there, but life is, one step at a time.

Re: Re: 8D Lockers
 

So to take the subject deeper, How can you get the ram locations output without interrupting the cycle times?
I'm not familiar with how it was done on the lockers setup.
A brief (or detailed) explaination of the process that was used would get the mental electrons flowing on a possible solution.
TIA

Am I missing something here? VEMaster allows you to take a Datamaster uni file or a Datamaster log file and run it through the VEMaster along with the original bin which then tweaks the tables. It does this by taking all the datapoints within a certain region then averages the BLM's over that datapoint. The limitations for $8d are lower and upper stock tables in the stock location. VESmoother takes a table -any table and just smoothes it. There is no log tweaking. It would seem that a VEMaster type program that will work with TunerPro log file is what is needed. BTW the VESmoother program has already been modified to work with Z69's extended VE table along with a Super_8dm.xdf that also has WBO2 support. You can input the original table or RBob's extended table or even use Z69's extended table as inputs. Plan is to have this released when a S_AUJP 'V4' is finalized and released. Moates and Mansur were talking about a program for this with TunerPro at least a year ago. I guess this has taken a back seat to other projects.

I've been playing around using a PIC to send RAM data to a PC running a simple Visual Basic routine. The PIC sits on the bus waiting for a write cycle. (i.e. R/~W line goes low) It grabs the address and data that was written to RAM and sends it via RS232 to the PC. The big advantage I see is that the data is only updated when the ECM updates it. (Avoids the issue of a 10x faster rate with the same number repeated 10x.)

My biggest setback is my use of a lousy card edge connector that doesn't always make good contact. (Remember it isn't always good to go with the cheapest thing out there!:D ) It's still in a development stage but showing promise....

Here's a picture of the 2 chip/ 1 oscillator board.

That is a great idea and really the first step for any group progress. That is what we NEED!

...far as wants, it might be cool to have the ability to adjust when the injectors start to fire.

Cool idea, I didn't know that was possible.
I take it that the PIC is fast enough to handle the output writes and convert them to RS232 within the time of the fast fuel/spark loop. What is the baud rate between the PIC and PC?

Actually, the data needs to be grabbed and turned around within an ECM clock cycle, ca. 472.5 nsec. Double byte writes to RAM require this.

RBob.

I take it you gave up on your code project again.


I can't decide wether or not to label all the stock tables.

I think the best way to get something to move forward is to select a ECM(s) and support both MAF and MAP cars with one bin. I think that would get a bigger audience and allow everybody to move forward at the same time. It would also eliminate duplication of effort.

I didn't give up on it. Just need to gain a better understanding of assembly language, that's what I'm in the process of doing. It just takes time...

Well, since it hasn't completely worked yet, I *really* can't say it's possible!:D I have the PIC running @ 20MHz (the fastest this chip can run) shooting data to the PC at 38400 (the fastest I've had luck using with other PIC projects). It's supposed to execute one instruction every 4th clock cycle if I remember correctly. I'd have to take a look at how many instructions are executed before "grabbing" the data to see if Rbob's time constraint is met or not...... I've just played with this on/off when other projects slow down a little. My ability to stay with one project until completion leaves quite a bit to be desired!

Where have you been?.
We've been though this time and time again.

Need to start with something that's simple. What allowed the Programming 101 project to succeed is having an organized group of people willing to put the time into a RESONABLE project.

Doing a proper MAF/MAP system is one thing, doing a MAP, then MAF system with one .bin is going to tie up alot of processor time, running meaningless loops.

The first thing that needs to be done, is setting a common goal. To date, that's not even happened. The folks around here are so splintered, I doubt they'll ever get much done as a community, I just base this statement on what's happend here over the last, 6+ years.