Results 1 to 15 of 22

Thread: Proptype Beagle Bone Black EFI cape

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Fuel Injected!
    Join Date
    Jan 2018
    Posts
    57
    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?

  2. #2
    Fuel Injected!
    Join Date
    Oct 2012
    Location
    Boynton Beach Florida
    Age
    61
    Posts
    83
    Quote Originally Posted by NSFW View Post
    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.
    Avatar is my motor 800 RPM 184ft Lbs Torque 18 inches x 18 inches x 9 inches thick external combustion engine.

    98 WS-6 full tube chassis rally car Aluminum Block LS2 (soon to be LSX 376)(in Storage)
    95 Suburban 6 inch drop, Pioneer DVD in Dash 5.7 TBI, 220cc 2.02x1.60 64cc heads, Stainless longtube headers 2.5 crossover 3 inch exhaust, LT-4 roller cam.
    2002 Seville STS

  3. #3
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    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!

  4. #4
    Fuel Injected!
    Join Date
    Jan 2018
    Posts
    57
    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?

  5. #5
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    53
    Posts
    217
    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.

    scope pattern interpretation sample.png
    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.
    Last edited by vilefly; 09-13-2019 at 02:57 AM.

  6. #6
    Fuel Injected!
    Join Date
    Oct 2012
    Location
    Boynton Beach Florida
    Age
    61
    Posts
    83
    Quote Originally Posted by NSFW View Post
    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 View Post
    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 View Post
    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 View Post
    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 View Post
    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.
    Avatar is my motor 800 RPM 184ft Lbs Torque 18 inches x 18 inches x 9 inches thick external combustion engine.

    98 WS-6 full tube chassis rally car Aluminum Block LS2 (soon to be LSX 376)(in Storage)
    95 Suburban 6 inch drop, Pioneer DVD in Dash 5.7 TBI, 220cc 2.02x1.60 64cc heads, Stainless longtube headers 2.5 crossover 3 inch exhaust, LT-4 roller cam.
    2002 Seville STS

Similar Threads

  1. question on black box pcm
    By myburb in forum GM EFI Systems
    Replies: 0
    Last Post: 05-22-2018, 10:06 PM
  2. Black box PCM help
    By Nasty-Z in forum GM EFI Systems
    Replies: 4
    Last Post: 01-03-2018, 06:07 AM
  3. XDF for 1998 Silverado Black Box?
    By Chas in forum OBDII Tuning
    Replies: 3
    Last Post: 04-01-2017, 05:56 AM
  4. What if, Black Box PCM repurposed as TCM?
    By dave w in forum OBDII Tuning
    Replies: 46
    Last Post: 02-23-2016, 08:10 AM
  5. Black box pcm data
    By mecanicman in forum OBDII Tuning
    Replies: 15
    Last Post: 01-04-2015, 07:06 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •