Proptype Beagle Bone Black EFI cape

This is a Fun project that I am working on.
I have a 98 WS-6 that I am modifying next year.
I am dissatisfied with current aftermarket offerings for ECU.
So I decided to build one myself.
I like the Beagleone platform and have made lots of other complex projects using them.
The boards are serial and Cam coms
input interface and output driver
My intent is a sequential multi port, multi fuel, ECU with a in car Double DIN chassis to replace the old Bose system in my WS-6.
Touch screen on the fly tuning and a nav entertainment system in one.

Attachment 14451

how much cheaper it will be then Megasquirt witch combined with WB, tablet and Tunerstudio is ? Will it have boost controler, launch control, nitrous control, table switching etc ?

bets regards

Much Cheaper
I did a project with MS2 V3 module and needed trans control, multi pump fuel pump control, Ac control and Speedo
So I would have require 3 additional MS2 V3 modules at @250 each not effective.
ended up using a Teensy 3.6 with the MS2 V3 total PITA took four months to get the code working together.
In the mean time I saw that the Gokart EFI guys used a Teensy 3.5 with a Arduino Mega adapter for one of their builds. Now called Speedduino cool have not tried one.
What I ran into with the Microsquirt universe was the low output count and not much documentation on their BIN firmwares that I saw.

The BeagleBone has a lot more RTC GPIO and if I am going to code Id rather do it on open hardware software.

One main reason for me is that I was an analog Fuel Injection and Mechanical Fuel injection GURU of sorts back in the very early days of EFI made lots of badass turbo BMW, Mitsubishi, and Nissan using Jectronic Not L-Jetronic we had only exhaust temp for feed back no O2 Lambda sensors. I started with my relationship to GM when the DFI olds and Cadilacs first came out I believe it was @1980 or so. I repaired crap loads of ECU at our carb shop.

Most of the integration at that time was still analog even though the product was called digital.
Someone got the idea that a square wave meant digital.

In the early days each stage of sensor input fed integrators and comparators the Air Flow sensor was a variable resistance mechanism.
The TPS was not a continuously variable resistance but a stepped switch that the accell curve adjustment was made by different resistors. You could lengthen or shorten injector accell pulse integrator by adding resistors soldered to the PCB.
Attachment 14453

With the advent of micro controllers the idea of approximation tables became normal.
The reason behind the use of 4-8 bit micros over discrete was that they where easier to mass produce and later change the tables for approximation.
With analog systems the calculations where absolute and infinitely more accurate when properly tuned.
In computer lingo the curves require the use of irrational numbers that binary math can not accurately handle the use of floats and longs still approximates to the byte width of the struct analog does not.
So in the early days of controllers your word width might be 16bit but the processor was 4 bit.
Because of this the look up table was much faster and the results more predictable.
Today with 32bit and 64bit word widths we can more accurately calculate the true values.
For instance Two values that can be correlated to provide more accurate combustion monitoring are the Spark discharge voltage / period and the exhaust pulse temp.
This is much more accurate than O2 sensor readings.
The variable frequency MAF and Flex Fuel sensors also provide better linearity than Speed Density "Map, TPS, O2"
Most of the GM ECU are built with slower than 66Mhz processors a lot more tasks can be done with 1Ghz in the same time window.
So if I have a V8 at 10,000 RPM it is producing 1334 instance per second giving you 750uS to calculate fuel and spark. Thats 750,000 clock cycles at 1GHz.

I am really surprised that I have not seen a realtime ECU out there.
Everyone seems to be using the tables method as far as I know.
Makes for good industry support not so much for the shade tree or backyard hotrodder.
I think that this is part of why people are still pulling EFI and putting carbs on.
Here in florida the fuel is at least 10% alcohol and I have yet to see a carb that works correctly with it.

So in my EFI the display will not be the FUEL Spark tables that the tuner guys love but a simpler interface that would make sense to a carb guy.
Idle
Warm up
Front pump cam
Vacuum secondary spring weight
jet size
Squirter size
and the like
Nice touch screen interface so you can put a "fatter jet" in while driving.
When not tuning the screen will be a gauge cluster and like a NAV or entertainment system.

And I have heard that Holley has a little screen that does something similar just not interested in paying such high prices for the name.

So cost wise the first one is MUNDO labor intensive.
But the modular design will allow you to use the cape for as little or as much as you want.
In my first setup I am developing the cape with GPIO set up for my LSX motor in the WS6 so 16 injector control and 8 coils on the output board.
For the Truck the output board will only have 2 injector channels and a single coil driver.
The transmission board will be for a 4L60E
For the Cadillac the input and GPIO board will have a micro controller to make sense of the crank sensors and Cam position as well as 8 injector and 8 coil drivers.
The transmission board will be for a 4T80E and should be fine for 4L80E.

SO on both my WS6 and the STS the dash is Cam bus driven so the serial board has this capacity.
On the truck not needed just a ALDL for codes.


I am probably open sourcing the whole project and if requested do build to order through Fritzing or similar, much of what I am planning to use is in the Arduino community already.

Oh man, I am going to follow this thread. Is this the place you will be updating your progress, or is there another forum or site I should also follow?

I own a BeagleBoneBlack that I'm hoping to use with MachineKit https://www.machinekit.io/ for a CNC project I'm working on. MachineKit is a port of Linux CNC http://linuxcnc.org/

Thank you in advance for starting a project like this.

Quote:

---

Originally Posted by DavidBraley

Oh man, I am going to follow this thread. Is this the place you will be updating your progress, or is there another forum or site I should also follow?

I own a BeagleBoneBlack that I'm hoping to use with MachineKit https://www.machinekit.io/ for a CNC project I'm working on. MachineKit is a port of Linux CNC http://linuxcnc.org/

Thank you in advance for starting a project like this.

---

Sure man it's self interest not so much altruism I have a 1998 WS6 in the garage that I need to go through the motor on.
I have been considering doing a LS376 complete set up but still not really happy with what I have seen out there.
With my health effed my income has plummeted so I have the skill and the knowledge I am putting it to use.

I have been fighting with the electronics on my 2002 STS for about 3 years now so it is another candidate for the controller.
I also have a few LT1 engines in the garage that will need controllers.

SO the order of conquest is the truck overhaul,
Then STS heads are coming off to try and find a miss and the rusting grounds somewhere in the car.
So as I clear out my backlog I will be building more for the aluminum LS1 340CI 340HP in my WS6.
I got #628 of 628 cars made on the 1997 order so It has a single exhaust outlet and an aluminum block LS1 that all the part number say it's a 2002 LS2 corvette but it is stock factory.
The car also has a TCI raptor and a full Spohn Tubular chassis from the factory.
The car is 1.5 inches lower than production 1999 and 6" wider at the rear wheels than the 1999 production.
2 cars delivered to south Florida in march of 1998 mine is one.

While I still had my lab closed in December due to Kidney failure < sucks old war wounds.
I had a Milltronics RH30 sold it to buy a couple of more years alive.
I still have a Jet 7-48 lathe and a small mill.
I am converting the mill to CNC as well.
I have looked at the LinuxCNC I used the python macros to generate Code for my big mill.
For my HF mill drill I just need two axis and a plunge not really three axis.
So what controller I have chosen is the BPI-M3 because I have a few of them.
I have 16 Beagles in the drawer as well but The M3 is so much faster.

The actual stepper drives and DRO I am using GRBL on a Arduino Mega 2560 and Igaging Ezview DRO.
The M3 will act as the Controller for the GRBL

On mine I am using inkscape with a bunch of Macros to generate GCode from Colada files exported from Sketchup.
For my needs I am drawing the stuff I want to make so work flow is unlike a Machine shop for simple stuff I can use the DRO and the Axis like power feeds.

The beagles make great GPIO drivers and are pretty well suited for EFI.
One wonky thing on the Beagles is the Power VR if you use a LCD display cape it works fine but through the hdmi it can only display video in a window.
The M3 has the same issue.
The Sunxi and armbian groups DO NOT like the powerVR graphics chip so display graphics are a bit processor intensive.
Make sure that when you set up your axis drives you are realtime.

On mine I am offloading the interrupts to the MEGA that way it will work more like a conventional old style CNC.
Ie G-Code command wait complete next block
On the beagles Interupts will stop motion feedback so display will "jump"
You may want to use the beagle as the display driver and use serial UART to Arduino Nanos for each axis that way your motion and limits will not effect the display.
I am also playing with using a serial to parallel shift register to control stepper drivers as a way to offload motion control.

One of my guys built a large format 3D printer I still have, He intended to use linux CNC but got caught up in getting the Steppers interfaced.
The base code works to exercise the axis but it does not conform to any of the linux CNC hardware examples.
I did not have the time to integrate the difference.
I seldom have need for 3d printed parts so it has been sitting for four years now.

Well, you understand this stuff better then I do. I try my best at the micro-controller and electronics projects I make, but I admit to relying on what others have figured out to succeed at it.

I'm more of a handle cranker. I've been impersonating a machinist, welder and fabricator now for 45 years? My first job was in a machine shop when I was just starting high school. I have a very modest, but capable shop here at home.

This EFI stuff is really interesting to me. You will find some very smart and helpful people here. They are even friendly! Which has not been my usual experience with some smart people (or people who think they know what they are doing)... I feel super lucky this place even exists.

Please keep use up to date on your progress! There is a very cool project here going on right now that lets people read and write to the GM Gen 3 PCM's (like the 12200411).

Take care sir!

No need to reinvent the wheel in this case as its already been done.

https://speeduino.com/wiki/index.php/Overview

You can't buy one that's already built but you can buy all the parts and PCB from the company and the prices are very fair IMO.

Early BETA of the ignition for my Truck
Small Cap HEI freestanding EST and Knock
Been sick and struggling to finish my Truck
But I needed a EST controller to get out and about.
Stock tune throwing 60 degrees at idle due to low vacumn and knock sensor going crazy with the exhaust note and roller rockers.
Very mild slight lobe due to the Heads and Cam

So runs nice and smooth Timing bypass disconnected runs crazy connected.
Makes sense original motor was <8 to 1 so even on cranking GM has the timing advance way too high.
Best manifold vacuum on my motor is around 15 degrees advanced.
9.76 to 1 max mechanical advance old school would be around 37-38 degrees.
Dwell angle about 5% at idle and less than 35% WOT

The calculations are pretty simple and a Arduino Nano is fast enough to do upto 10K rpm.
Like I said the New EFU will be Modular so the first Beta module is the EST and the circuit to meet the Code 42-43 OBDI tests.
Attachment 14569

The schematic shows connections to both the Module and ECM pins
If you want to use a GM 7 or 8 pin Module with a boosted or carbonated engine just do not connect the ECM side.
The only really important connection for EFI 1995 and earlier is the PIN R signal.

EST bypass disconnected my Module will use a preset advance firing the Coil somewhere around 10 degrees advanced.
Once Bypass Goes High 5V the module fires the coil based on the EST signal both the coil dwell and the Timing are controlled off module.
Dwell angle on after market coils is how you stretch the the spark duration the one I have is advertised at 225ms with stock dwell and 0.50 plug gap the duration is just a bit better than stock.
There are a variety of GM 8 pin modules with various dwells with bypass disconnected.

If someone else would like to make this into an MSD the spark can be interrupted at .293 x Spark duration.
If you know your coils secondary inductance , primary inductance, primary resistance and the base ignition modules current limitation you can calculate how long it takes for the coil to charge and discharge as a spark.
The spark can be shut off by grounding the negative of the primary while the spark is discharging the coils energy.
If you shut the spark off when the coil gets to .707 of it's full charge then recharge the coil it will spark again when you open the ground.
This will work fine with this EST as the ECM gets its signal from the module pin R.
On my truck the TACH signal comes from the coil so MSD would trash my tach reading.

Before the auto flame kicks in I am using the Nemonic MSD for Multiple Spark Discharge not the popular brand MSDtm.

Stock Chevy truck modules switch from cranking to run at 450RPM.
Coil dwell changes even if there is no EST it works out to about 3 degrees at idle so this is very week and will cause cols start and rough idle.
Coil Dwell is preset for Stock GM external HEI coils.

We used to have a couple of companies that made multiple point replacement plates for the pre HEI points style distributors VERY VERY few people who used them ever set them up correctly.
Most old timers had a dwell meter and would set both sets of points to get the maximum dwell at idle.
The correct way to set them was on the machine at 30 degrees at 3000 rpm.
This is how we routinely got 8-9000 Rpm out of de-stroked small blocks and points ignition.

Today most HEI coils saturate at about 5800 RPM the LT-1 GenII modules can push MSD tm StreetFire tm coils to about 8000 rpm
It is the dwell that charges the coil
In this application I do not need more than 5400 RPM so my dwell settings will drop out around 7000rpm with too week a spark.
Some one better at coding may be able to play with the interrupt timing and get a faster EST signal out of this EST.

In my code the settings section has the coil parameters and it calculates the dwell on start up. < change these for your setup.
The code will also calculate the correct maximum advance for the compression ratio of the engine.
You must scope the knock sensor and adjust your threshold on my trick the valvetrain and Headers are way above the stock ECM sensitivity.
I have confirmed that the one wire knock sensor does have a variable signal output based on the acoustic amplitude of the vibration.
The signal rides on a 2.5 DC bias and max 4V peek to peek only care about the compression part of the signal that is positive.
On the next iteration I will be using a filter cap to average the spikes as a different way to do the thresholding.
In my code after the plug fires it reads the sensor for a signal. So if I have ping it will pick up before the next firing.
The knock signal threshold increases the count then reduces the timing.

Vacuum advance is great but not really necessary and on low vacuum or boosted applications it can cause problems.
I have seen that many tuners will map advance to vacuum you get a bit of power this way on mild engines.
Old School I had a distributor machine and weight kits with springs very seldom did I use more than about 10 degrees of advance from manifold vacuum most often just locked out the vacuum advance completely.
This EST controller reflects those Old ways.

This is fantastic. Most of it is over my head, but I'm using it as an excuse to learn something!

I truly hope you and your family are surviving the hurricane!

David

Super cool project, I love it!

I've been thinking for a long time that an Arduino Due might make a good base for a fully open source ECU (open source hardware as well as software) but the BeagleBone Black is probably a better choice. Tons of I/O and way-more-than-enough CPU and storage.

The Speeduino being 4-channel fuel and 4-channel spark kinda kills it for me - it's great what they're doing, but it seems like they're just one hardware revision away from proper control of a V8. And I want my fuel injections timed with the valve events at idle. :)

Personally I like the table-driven approach of typical ECU software (especially 2004+ Subaru stuff since it's all 32-bit floating-point) but if you come up with open-source designs for capes that handle interfacing with injectors, coils, sensors, etc, then I bet you'll find other people writing different kinds of software to control it all. Probably including me, eventually.

Are you using Linux on the BBB, or does it boot straight into your ECU software?

Code completely rewritten
Auto adjust for Knock sensor added
redefined digital IO routines
reprogrammed the Timer registers
Now running stable on the bench going in the truck later today.

Using dynamic array now instead of realtime array loads t ram on startup.
Auto bypass added for loss of signal etc.

Added a .1uf cap to the Knock sensor and setup the processor ADC to free run to be sure and catch knock events.

Attachment 14600

26 degrees advance at 1500 rpm

Attachment 14601


@16 degrees at 750 rpm

Attachment 14602

Breadboard EST Module
Attachment 14603

My new Engine 5.7L Lt1 roller cam Roller Rockers RaceMaster 220cc 64cc CNC 202/160 Top engine kit DMI headers 3 inch single exhaust.
52mm TBI salad bowl Racemaster universal 60KV coil NO EGR.
Attachment 14604


My truck 95 suburban Lowered 6 inches Torque arm rear suspension.
Attachment 14605

New code and Schematic Board layout attached

Some other Build Photos
Fresh Driveway overhaul
Attachment 14607

Nice fit on these headers
Attachment 14608
Attachment 14609

Same photo color adjusted so you can see the Torque arm
When you drop suburbans by leaf restacking you run the risk of breaking the springs due to rear end windup.
The trick is to mount a bracket to the rear of the housing and bolt on a F-Body torque arm just stops the wind up.
Attachment 14610Attachment 14610

Trick CHEAP starter I bought this for my Caprice originally 12 years ago. Still today it's like 40 usd when you go looking for a starter on a small block there was a gear reduction option for the 1995 Caprice POLICE 4.3L tiny motor it uses the same flywheel as all the roller cam block engines no shims needed. I have actually moved the truck using this starter without trashing it.It spins the 5.7L at 500rpm at start up really cool find. The housing is like 6 inches long the motor is 2.75 inch diameter so headers NO PROBLEM.
Attachment 14611

Quote:

---

Originally Posted by NSFW

Super cool project, I love it!

I've been thinking for a long time that an Arduino Due might make a good base for a fully open source ECU (open source hardware as well as software) but the BeagleBone Black is probably a better choice. Tons of I/O and way-more-than-enough CPU and storage.

The Speeduino being 4-channel fuel and 4-channel spark kinda kills it for me - it's great what they're doing, but it seems like they're just one hardware revision away from proper control of a V8. And I want my fuel injections timed with the valve events at idle. :)

Personally I like the table-driven approach of typical ECU software (especially 2004+ Subaru stuff since it's all 32-bit floating-point) but if you come up with open-source designs for capes that handle interfacing with injectors, coils, sensors, etc, then I bet you'll find other people writing different kinds of software to control it all. Probably including me, eventually.

Are you using Linux on the BBB, or does it boot straight into your ECU software?

---

On the BBB its linux I assemble my own distro packages for other projects so I will prob do the same here.
Keeps rev control in house so stuff doesn't break from updates.
I am liking the QT5 stuff I have played with although it is another learning curve.

Had encephalitis in 2015 whole left hemisphere was infected so to keep my wits I compiled from source an entire Linux OS over the year.
I still have issues but the coding keeps me busy while I am having problems.
I am also in 2-3 stage kidney failure so if I exert myself to do something I pay for it for weeks of pain.

The truck overhaul only took me 10 days to complete the mechanical but I have not completely recovered after 4 weeks.
So I sit and wait for the lactic acid and other toxins to finally leave my body.
No one who has not experienced it could understand it really really hurts not any one spot but the whole body.

I am a very large guy before I got sick I weighed 260lbs with a 34 inch waist 60 inch chest.
I lost 40% of my muscle 76 pounds of muscle.
I have gained back about 50 since the beginning of this year.
SO I go 250 with a 38 inch waist.

The electronics and programing keep me level.

As far as the look up tables I am not a fan I know the formulas and they are not that complex.
I started in Fuel injection in the early 70s when Hilborn and Chris Victor still came out to help you at the track Dick Morroso Sr was just a guy with track on his farm.
Gulstrand Mosler Garlits Iskedarin and many others where just guys at the track.

We had a carb shop called E&D carburetor I was the D fuel injection was mechanical.
All the same stuff you see in a table is pretty easy to do with hardware.
The hardware is infinitely more accurate.

The issue is that software can not do irrational numbers well and every calculation on a engine is an irrational one.
Meaning there are no integers in the products of the calculations so you have to approximate to use tables.

For example the quad calc ((-b ± sqrt(b² - 4ac)) / 2a generates half of a parabolic curve you can find every torque and horsepower curve within an arc segment of this type of curve. IF b² - 4ac results in a prime such as 1 2 3 5 7 11 the product of the SQRT will be irrational.

The old analog mechanical and analog electronic systems have no problem calculating these curves real time not so much for binary digital.

The look up tables come from very slow processing days and just have never been abandoned I think one reason is the guys I went to school with in the 1960s where already in their forties and fifties. I have only a cursory remembrance of programing analog state machines at Pen state in 1969 - 1972 but they where idle for nonlinear and irrational calculations.

One of the small advantages of the use of tables is the predictive possibility of N-alpha way of tuning but almost all tuners including myself love closed loop and there is a delay in speed density making it reactive not predictive. You have to wait for the last cylinder or last cam sync pulse or the O2 or the thermocouple change that happens after the cylinder has fired.

I have intended to use some tables like in the EST but load the variables at boot and generate them at startup.
This lets you make changes and implement them at key cycle.
For instance on sequential fuel injection your reactive update takes one full revolution to implement anyway.
The fuel injector firing is best done twice per revolution pulse after the intake closes and again when it first opens.

I also love waist spark on turbo motors at higher RPMs with a scavenging cam you can actually increase exhaust manifold pressure and boost. Done this recently.

So instead of a MAP/TABLE metaphor I intend to allows fine adjustment of the variables that go into calculating the values.
As an example I wrote a simple idle start up routine that sets the knock sensor threshold on the EST automatically.

Setting up a Hilborn system I used something called a magnahelix to measure actual air flow and a barometric valve to measure air density the proportional fuel valve was linked using an adjustable lever ratio. The old mechanical corvette systems had a bellows that did the same thing the Mercedes jectronic pre lambda used a 4.75 inch diameter flow valve to measure the incoming air flow. Today MAF hot wire measure the rate at witch a known resistance heats and cools to calculate air flow. I made a electronic magnahelix using two MAP sensors and a a venturi tube that actually give better readings than a MAF.

Another very cool thing I have been thinking of is using the reflected load on the individual coil paks as a way of getting faster feed back of combustion.
I need to find some very fast ADC samplers something that can sample in the 25MHZ range. To get all the data there. My old analog scope needs some rare Tubes so I have not seen the old spark profile for a long time.

On the arduino DUE IDK I recently bought one off DX and played a little with it for a tool I am making to read GPS and accelerometer data to calculate horse power drag and torque. I switched to a nano and an accelerometer for a dash mounted lateral G and Horse power gauge. The due is interesting but I had some issues with polling I think might be related to the IDE rather than the processor.
On the beagle there are some short comings as it is a System on a chip and even though there is time slicing it is not realtime. As a work around I intend to use task specific processing in each of the modules like this EST I think my new rule is if you need to interrupt use a dedicated processor. On the LSX I may just use atmega8 processors for each coil and injector pair IDK yet I have to look at the Timer control on a few of the development boards to determine which I will use.
I have used teh Teensy controllers lie the software end not so much on the hardware end. Very low current in my application I had to use driver FETS on all of the GPIO of the teensy the current listed is 250mA total that is extremely optimistic after 50 minutes of 40ma I burned one up the actual spec is more like 50uA per port of 8 pins not the voltage regulator rating of 250mA.

Very cool to see the Arduino platform used as an ESC. Since this is an LT1, you wouldn't happen to know the pinout of the ESC module on the LT1 PCM, would you? The 8-pin connector?

Following along for updates as well, I love all the custom engine control engineering going on on this forum!

Sorry to hear about your health issues, that sounds like a tough burden to bear.

I wouldn't worry much about irrational numbers, since the 32-bit floating point system gives lots of precision. And if you really want more you can use 64-bit ("double precision") with a small performance penalty - but with something like the BBB, there's probably still going to be plenty of CPU power. The time periods between sparks or fuel injections are long enough to do a lot of math.

One of the nice things about lookup tables is that they make it pretty easy to visualize what's going to happen in the engine. With RPM on one axis and air on another axis, you can immediately see what the spark timing will be, or what the AFR will be, and you can see how those values will change in response to changes in RPM or air. I'm intrigued by the idea of using math instead, but in order to get my head around that approach I'm sure I'd have to start by using that math to populate a table to look at. :)

If I'm reading you right, you're going to use the BBB to come up with a schedule of fuel and spark events, and then use a peripheral processor to trigger the injectors and coils according to that schedule?

What information can you get about the combusion from monitoring the coil packs?

I think I can answer the coil monitoring question, assuming I have a clue as to what will be designed (which I don't).

Not sure if it was intended to go Ion Sensing or not, so I will stick to conventional scope patterns that can be picked up on the primary side with a little work.

Attachment 14623
This is only a 1/3 the info you would find out. This is just an example.
Hope this helps. Ion Sensing would give more data, for sure, but under 4k rpm I think.

Sorry for the long delay I have been pretty sick.
Tonight I took my first test drive with the new fuel injection system and trans controller.
Ran really well
Raining so I had some serious tire spin 130mph just pulling away from light.
Ran it over to the gas station and put some gas in recorded the trip back.
Attached is the raw log from the trans controller.
I haven't figured out the PCS 3-2 TCC PWM modulator stuff.
This trans has a shift kit in it from an unknown source and unknown mod.
So I do not know if I will even use the PWM stuff on this build.
I have giant torque from the new motor and I Torque arm on the rear end so I don't think I mind the heavy shift feel.
The ProtoType EFI controller is now stable and running well.
The Auto tune function needs some work the EEPROM library from arduino does not have any error handling.
Also write time for the library is really slow I may rewrite the Software library to get better speed from an external Fram or Mram NVRam chip.
So currently I have the trans and EFI running on my own version of a Mega2560 controller
The code for the trans will run on a leonardo Atmega 32U4 just fine.

The code base shares nothing from the GM or Megasquirt methodology.
Been trying to keep the Carburetor metaphor to make it easy for the every guy to understand.
NO Volumetric efficiency tables, Not N alpha either.
The metaphor works like this;
The engine is an air pump you can roughly estimate the weight of the air in the cylinder using the Ideal gas laws.
Didn't bother with the remolds numbers or flow dynamics "Turbulence" I really like using HUGE heads for any of my builds and less cam.
The engines flow more air but usually stumble really badly with Carburetor like a tunnel ram on a small cid engine it will make a lot of power but good luck trying to drive it.
I use 220 CC intake runners with .477-560 lift 260 duration 114 lobe centers 220 intake 192 exhaust heart shaped angle plug heads.
So not much idle vacuum so when the throttle is opened manifold vacuum drops rapidly.
Also you have to run a free flowing exhaust or the exhaust reversion from back pressure kills all the gain.
This config makes an easy 400Hp Na and I have done a few boosted to mid 800 at flywheel on turbo you have to run rich and use waist spark to bring turbine up to speed faster also smaller trim than whats popular. I started turboing cars using diesel cartridges in the 1970s. As for super chargers Dyers and Lanthams were on Chrysler garbage trucks but you basically had to steal them to get one. I had a buddy Red Walker who built a Blown V6 made the cover of hotrod magazine in the early eighties or late 70s I managed to convince his dad to trade my work for a 671 back then.

On my EFI I average the manifold vacuum and use it only to select a range so the part throttle MAP drops 30-40 % on tip in but it takes about 240ms to change out of the fuel range.
The TPS is averaged 1 of 10 at 1.2ms between samples the TPS Delta Over Time is used as a direct multiplier for the enrichment pulse.
So it acts like the jumbo Holley Q pump for tunnel rams.
https://www.carid.com/holley/50cc-ac...mpn-20-11.html
The lean bog on tunnel rams comes from no vacuum signal at the power valve port to draw the fuel over the bowl height you have to dump a crap load of fuel into the cylinders at tip in to equal out the increased amount of air weight in the same volume at higher pressure.

So TBI EFi works much better to do this and I have had difficulties tuning this with both Cats, Megatune for OBD and Tuner Studio for MicroSquirts.
On my EFI system the accel tune is accomplished with a hand held 5 button switch to use while driving.

Since the current controller is a Atmega 2560 so I could use the free Arduino Code base I am using a very large single table MAP by CLT 42 x 39 cells this covers each of the plateaus of stability with regular air. Air density therefore weight is not exactly linear it is a compressible mixture and even at sea level there are stable ranges that air exists in. I remember that the physics books claim that curves are completely linear but then there is the whole additional field of fluid dynamics that deals with the nonlinearity.
So according to CLT and Map a base fuel byte is selected this byte represents the weight of the air in the cylinder / the Air fuel ratio.
This byte is multiplied by the JET Factor this number is based on the actual flow of the TBI on the engine.
Going from the advertised flow rates of my GM TBI mine should have been 0.008 after some tuning mine is 0.05225 so the advertised 60lbshr is not correct mine is more like 20LbsHr Thats fine for this truck I rev limit at 6000 but will never run it above 4500. That gives me like 3.3Ms to squirt between firings. At idle I am currently running about 210 to 280 us. At start 900 to 1200 on a cold day.

After the Jet factor I multiply a trim from a table stored in EEPROM one byte 0% to 250% of calculated fuel demand. The table is MAP times RPM and while the Auto tune was running I saw that it fattened up at about 2500RPM like I expected for the Dynamics of the High rise Intake.
I am uncertain if the EEPROM library just writes too slow and collides with the next firing pulse or the EEPROM cll is bad and it faults.
With the research I have done so far I understand that the default library erases first then writes even on update this is not necessary for a single byte write so I will have to change that.

The algorithm for the calculations is pretty close to done I will at some point in the future port the code over to a free standing application to run on the BBB.
On the BBB I can just run the calculation RealTime rather than use the spreadsheet results as a table.

I will post a full package in the next couple of days.

Here is the Package on my desktop that is running the truck now.
I will post a revised as I gather the mods and finish documenting the build.
TBI EFI running fine with GM TBI
Trans controller mostly working

Quote:

---

Originally Posted by PeteS

No need to reinvent the wheel in this case as its already been done.

---

Yep For a mazda Miata with a crank trigger using Tunerstudio it's A Nice Job started following them when they called it GOcart efi or something like that.
However Although I am proficient with TunerStudio MegaTune and Cats tuner I really want to get away from the whole tables IDEA my intent is to design and build and actual calculating system, But for starters I needed to build something that would work with my favorite engine build. I have had limited success with Cats tuner using GM66ECU on LT1 but have had to compromise way too much to use tuner studio on different builds.

I finished a Crossfire corvette MicroSquirt integration two years ago and it was pretty much miserable the outcome was good but the Microsquirt ala Tuner Studio works best with what it was designed for a crank triggered 4 cylinder.

I have seen the huge push of conformity to a most popular set of parts for engine builds.
I seem not to conform and Have built crazy huge power with cheaper less common parts over the years.

Once I get my Mill set up again I intend to start building a LT1 using modified Gen1 SBC heads and either 4 tiny Turbos or 4 AiSan 30CID Screw Compressors.
These are the little compressors with the AC compressor clutch pulleys.

I also am thinking about fitting a Later model M122 blower to my STS cadillac.

As far as the wheel invention like I said I am not really satisfied with whats available and have the skills to do this.
The other thing is these available options are not really suitable for easy rapid adoption for a typical home garage mechanic.

Quote:

---

Originally Posted by NSFW

Sorry to hear about your health issues, that sounds like a tough burden to bear.

---

Yep lived longer than anyone else I or my doctors are aware of.
I currently have only 1/3 of one kidney I have to watch everything I do and avoid toxins like crazy.
Still sick for days at a time. But 7.5 years beyond terminal

Quote:

---

Originally Posted by NSFW

I wouldn't worry much about irrational numbers, since the 32-bit floating point system gives lots of precision. And if you really want more you can use 64-bit ("double precision") with a small performance penalty - but with something like the BBB, there's probably still going to be plenty of CPU power. The time periods between sparks or fuel injections are long enough to do a lot of math.

---

Yep current math with TWO big tables and 4 sensors works out to about 500us on my BETA prototype.
The issue with 32bit is that most of the floats are significant out nine or more points.
The MOC921 and The Atmega series are significant out seven points.
The Atmega has no hardware division so you have to invert and multiply and that is where the float precision is lacking.
The cross table 3d map would best be calculated in a vector unit rather than iterative like current offerings.
Nvidea and Motorola have Vector processors but cost prohibitive.
EVERY thing else is iterative including all the bitcoin basics and high end graphics cards.
Even the Xeon PHI that I have written much for is iterative while still in decent health I used to build extreme High Performance Computers.
Not High Availability Clusters but unified backplane HPC last one I designed and built was in 2016 with 608 64bit processing cores and 96Tera Byte of bandwidth on QPI busses. It placed 375 million voice mail messages in 4 seconds for a political ad campaign.

Quietly the BBB has a much maligned PowerVR vector processing core the popular boys and girls have chosen the favorite Mali core for its ability to playback Mp4,MSMP$ and MKV full screen. ALA PI series.

I have used these BBB just for the vector unit for calculating 4 billion unique 2048 character pallandrom prime numbers to use as RSA keys.
I made a small cluster using a modified version of the PAPERS protocol for task scheduling on the hardware,

Quote:

---

Originally Posted by NSFW

One of the nice things about lookup tables is that they make it pretty easy to visualize what's going to happen in the engine. With RPM on one axis and air on another axis, you can immediately see what the spark timing will be, or what the AFR will be, and you can see how those values will change in response to changes in RPM or air. I'm intrigued by the idea of using math instead, but in order to get my head around that approach I'm sure I'd have to start by using that math to populate a table to look at. :)

---

Yep thats conditioning I do the same thing I wrote into the prototype a couple of screen print routines so I could see the tables.
ViEWTABLES lets you see the MAP VS Coolant table
CT lets you see the crazy tables prints out Temp x MAP x RPM
EEPROMDUMP lets you view the self tune and create the final trim lookup byte array.

Quote:

---

Originally Posted by NSFW

If I'm reading you right, you're going to use the BBB to come up with a schedule of fuel and spark events, and then use a peripheral processor to trigger the injectors and coils according to that schedule?

---

Right now yes I have been unable to find cheap openly available addressable 16bit timers the ATmega series so far seems to be working with hardware integration nearing complete. The metaphor is much different than Tuner Studio or MEgatune mainly because I always feel held back by less than optimal knowledge of the software suites. One pet issue I have is that the tables seem way too small for what I know other EFI use 12x12 16x16 or 8x8 for the table pitches my minimalist table is 1600 cells. I watched the address stream at idle making changes to about 30 cells this detail is not available on currently offered products. I came from the mechanical fuel injection world and not just repaired but designed and built mechanical fuel systems in the early days. All analog digital is an approximation of infinite variability.
Specifically the PowerVR graphics processor of the Beagle and the A83T lets you calculate the actual vectors and curves like the reynolds numbers that make up the Volumetric efficiency curves that are approximated by the tables.

Quote:

---

Originally Posted by NSFW

What information can you get about the combusion from monitoring the coil packs?

---

This si great,
In the early days upto recent no one had actually photographed a flame front expansion or ignition in a combustion chamber so there where many competing theories.
I probably will screw up who owned what but the theories
One I think Champion believed that ignition occurred when the spark plug shed minute particles of metal and the combustion began as a thermal process.
Another was that the physical blue corona discharge actuall caused the ignition Mallory,MSD,Accel,GM,and many others.
Another believed that it was the heat of the flash Ford,Autolyte etc.
A guy named Christopher Jacobs believed that is was similar to lasing action that once the total energy level exceeded the latent heat of covalence that ignition began so if energy in the cylinder exceeded a certain point the shift on the collapse of the electron clouds around the atoms would cause the cascade and the resulting drop int covalent bonding to a lower latent heat giving off the energy present in the chemistry through combustion. HE was correct and proved it by fitting microwave transducers to an IROC camaro back some time ago once started you could run any fuel.

New material science and faster cameras allowed true inspection if the process to take place in the 1990s

When I first studied the process I was taught how to use a Sun Scope analyser circa 1968 or so.
Had a very high resolution scope with a giant rear projection screen.

Every material known to man has a diamagnetic threshold and a dielectric threshold.
This its the break over voltage that is reached when looking at the scope dry air has a dielectric of 50K ohms per inch.
Each fuel mixture has similar ratings old 113 octane at 14.7 to one at .o35 inches was 12KV <-- rich lean
The rate of dissipation from the peak to the 70.7 percent of peak gives you the total volume of the dielectric <-- cylinder fill
The bottom peak minus 70.7% gives you burn completion time <--MAP LOAD
The ring at the bottom and the known coil impedance gives you a number proportional to ideal timing.

So the coil is a device typically an autotransformer that the secondary condition is reflected into the primary so you need not measure the high voltage side just the primary the high voltage side will be proportional to the primary measurement.
Automotive grade coil driver packs do every thing they can to isolate this and do a good job but all you need to get a precise low voltage scope trace is a .1 ohm resistor in primary series and a differential voltage follower.

So in short from the spark coil primary we can more accurately measure in cylinder Mixture Timing and Load by measuring the exhaust temperature we can calculate the total oxygen in the combustion. This can allow only the throttle position exhaust temp and coil primary to be the complete sensor feed back for an OPEN dynamic closed loop system.

I have been running the last rev of Board and Software in my truck for a couple of months now.
Three issues I know of
Idle Control sucks < known the time for the idle motor to actually change the idle is too long addressed it differently in the next rev of hardware.
Random Communication error -<<< big one occasionally the I2c gets interrupted by the ignition interrupt and either the trans controller crashes or the fuel crashes. Lots of fun when under hard accel it stuck in second and I hit the rev limit built into the pulse filter. Turning ignition off and back on resets the controllers in next rev of hardware I approached the whole coms thing differently. Using a single hardwired byte to convey O2 tracking for closed loop and analog distribution amplifiers to communicate Map TPS RPM and MPH between the modules. The Hardware Rev after the next I have moved all calculations off the timing controller so that only the injector pulse timer and the ignition pulse are being dealt with. On this next rev I am still calculating the RPM from interrupt period on the fuel pulse controller. It is not necessary to do so one rev three I am using a Frequency to voltage convertor to provide a RPM signal then calculation the air fill weight from Map, CLt and overlaying a Feed back Map based on RPM, Map and O2 feedback.
Trans shifts way too conservative. <-- this is just a preference kind of thing, the trans I have in the truck had a "Shift Kit for Towing" installed I have no change in Line pressure when modulated and no change in Torque convertor feel when modulated and no change in 3-2 downshift so I am only guessing that they bypassed accumulators and line pressure regulation at the valve body plate like the old B&M shift kits plate for 700R4. However my code tends to upshift sooner than I really like but I guess that it saves gas. In next rev I intend to have a higher shift point. I also am incorporating a mode switch and flappy buttons function to the trans controller.
Biggest change on next version -- direct calculation and no table for base fuel I worked out a pretty stable calculation that takes @470us and it is broken down into 8 separate parts so the base fuel updates every 2 rotations. This is actually faster than table lookups and eeprom reads. BTW atmegas have no division in the processor so all maths have to be iterated subtractions. However the hardfloat does seem to work so multipling a floating point does work pretty quick. So divisors are calculated and stored as const float at start up and used by multiplying.
I will be posting REV 2 drawings and Code in a few days, I drive truck every day but am pretty sick and have long periods of non-function.

Fantastic!