|
Originally Posted by bloodline
(Post 634209)
If I still want a throttle servo, I'll need to serve it at least every 40milliseconds :)
Why not use external A-D converters? Take the burden off the processor and just fetch the values in a single read operation. You can get very high quality 10 and 12 bit multi-channel converters quite cheaply these days. With the servo throttle in particular, I'd want the main and redundant sensors to be on separate A-D converters anyway. Don't get me wrong, I still think that you're going to die as a result of this, and probably take a lot of other people out with you. But you'll definitely get mentioned in EE Times and The SAE International Journal. :D I understand the mechanics, I need to know the flow rate per microsecond (I have found a webpage that claims 212cc per min on a standard injector, is this right?), You'll get slightly different values from different sources, which probably reflects the use of different fuel pressures. Also, in a pulsed environment, you have to take into account the lag time on both opening and closing. In general, we tend to figure that for a high-impedance injector of the type we tend commonly to encounter, the actual flow time tends to be around 1 to 1.25ms less than the commanded on time, give or take. what voltage/amperage they run at, and also if they need to be pulsed (i.e. if I supply continuous power will it burn out the solenoid?). The vast majority of all fuel injectors in the world today are high impedance, including all injectors found as OEM on '89-'05 MX5s. These were the first to be invented, and are still the most common in the sum of extant passenger cars today. High impedance injectors typically have a winding resistance in the general neighborhood of 10-14 ohms. Assuming a supply voltage of 12 volts, you'll have around 1 amp of current passing through each on, give or take. It's not necessary to regulate the supply voltage, you just put battery on one end and provide a switched closure to ground on the other. You can run them at 100% duty cycle and they will be just fine. Hi-z injectors are commonly referred to as saturated injectors, as their coils are designed to run in full saturation all the time. Low impedance injectors are rapidly gaining in popularity. They are often found in high-performance applications using very large flowrates, and are starting to show up as OEM equipment on more and more cars, as they also have a beneficial effect on emissions at idle and very low duty cycle. In a lo-z injector, the coil winding is generally in the 2-3 ohm neighborhood. Obviously this necessitates a more complex control scheme than simple on or off, or they'd just melt down. Also known as "peak and hold" injectors, you drive these by applying full voltage for the first millisecond or two, and then throttling them back to a much lower holding voltage. The idea is to slam the pintle open as quickly as possible by throwing gobs of current at it, and then, once it's open, restricting the current to only the level necessary to prevent it from closing without burning up the coil. This can be accomplished in one of two ways. You can either PWM it, or you can use a linear analog circuit to control it. PWM is the method implemented in the MS, and while it's easy to do and very efficient, it has the disadvantage of generating a lot of electrical noise. The National LM1949 is an example of a chip designed for linear control, as used by JBPerf in their Peak & Hold driver board. While going this route raises the parts count and also generates a lot more heat, it doesn't produce a lot of noise and offloads the burden of worrying about injector control from the CPU. It's a closed-loop device using a current-sense resistor, so you just give it a simple on/off pulse and it figures out the rest. As a result of all this, lo-z injectors have much shorter lag times than hi-z injectors, meaning you have much better control over fuel delivery at very low duty cycles, such as when trying to idle a 1.8 engine on 750cc injectors. (Don't laugh, some folks here are doing precisely this.) Whatever you do, don't get taken in by the old trick of just putting 10 ohm resistors in series with lo-z injectors and then driving them with a conventional on/off signal. This is stupid, bad, wasteful, expensive, inefficient, and defeats the whole point of having bought lo-z injectors in the first place. hmmm, timing from rising and falling edge would be much better... I'll add an option for it in my code, so it can be activated if needed. :) Traditionally, we start the ignition timer on the leading edge of CKP (75° BTDC) on the principle that this is the shortest amount of time that we can get between the trigger event and the actual ignition event. Less uncertainty. OTOH, as Jason and others have pointed out, crankshaft angular velocity is not a constant. The crankshaft accelerates during the first quarter revolution after a combustion event has been initiated, but then it starts to decelerate during the second quarter rev as the aforementioned combustion event concludes whilst another cylinder is simultaneously approaching the latter half of its compression cycle and increasingly opposing the movement of the crank. Would taking a sample at 5° BTDC be better? It means that you're free-running for longer on the timer, but will the crankshaft's velocity when at 5° be closer to its velocity at the time of the ignition event than it would be at 75°? Is there a physicist in the house? |
Originally Posted by Joe Perez
(Post 634217)
Right, I'd forgotten you were wanting to do throttle-by-wire. In that case, you'll have, at an absolute minimum, two TPSs (one on the pedal, one on the throttle shaft), and if you're smart and enjoy being alive, you'll have two on the pedal and two on the shaft, with cross-checking between them.
I was thinking about adding a fully redundant backup for the throttle, but that defeats the point of using a lowcost MCU board like the Arduino. :) If the entire ECU can be built as cheap as possible, then one could simply run two in parallel, and we have a basic FADEC :idea: Also, would anybody honestly, seriously and actually trust their lives to a £6 RC servo? Why not use external A-D converters? Take the burden off the processor and just fetch the values in a single read operation. You can get very high quality 10 and 12 bit multi-channel converters quite cheaply these days. With the servo throttle in particular, I'd want the main and redundant sensors to be on separate A-D converters anyway. Don't get me wrong, I still think that you're going to die as a result of this, and probably take a lot of other people out with you. But you'll definitely get mentioned in EE Times and The SAE International Journal. :D Nothing I could build would be road legal anyway :) There's a fairly comprehensive list of injector flowrates in the third post here: https://www.miataturbo.net/showthread.php?t=4288 You'll get slightly different values from different sources, which probably reflects the use of different fuel pressures. Also, in a pulsed environment, you have to take into account the lag time on both opening and closing. In general, we tend to figure that for a high-impedance injector of the type we tend commonly to encounter, the actual flow time tends to be around 1 to 1.25ms less than the commanded on time, give or take. While there are many variations in physical construction, there are only two broad classes of fuel injector, from an electrical standpoint anyway: high impedance and low impedance, or hi-z and lo-z. (Well, there's a third style used in direct-injection applications, but they're not relevant to us.) The vast majority of all fuel injectors in the world today are high impedance, including all injectors found as OEM on '89-'05 MX5s. These were the first to be invented, and are still the most common in the sum of extant passenger cars today. High impedance injectors typically have a winding resistance in the general neighborhood of 10-14 ohms. Assuming a supply voltage of 12 volts, you'll have around 1 amp of current passing through each on, give or take. It's not necessary to regulate the supply voltage, you just put battery on one end and provide a switched closure to ground on the other. You can run them at 100% duty cycle and they will be just fine. Hi-z injectors are commonly referred to as saturated injectors, as their coils are designed to run in full saturation all the time. Low impedance injectors are rapidly gaining in popularity. They are often found in high-performance applications using very large flowrates, and are starting to show up as OEM equipment on more and more cars, as they also have a beneficial effect on emissions at idle and very low duty cycle. In a lo-z injector, the coil winding is generally in the 2-3 ohm neighborhood. Obviously this necessitates a more complex control scheme than simple on or off, or they'd just melt down. Also known as "peak and hold" injectors, you drive these by applying full voltage for the first millisecond or two, and then throttling them back to a much lower holding voltage. The idea is to slam the pintle open as quickly as possible by throwing gobs of current at it, and then, once it's open, restricting the current to only the level necessary to prevent it from closing without burning up the coil. This can be accomplished in one of two ways. You can either PWM it, or you can use a linear analog circuit to control it. PWM is the method implemented in the MS, and while it's easy to do and very efficient, it has the disadvantage of generating a lot of electrical noise. The National LM1949 is an example of a chip designed for linear control, as used by JBPerf in their Peak & Hold driver board. While going this route raises the parts count and also generates a lot more heat, it doesn't produce a lot of noise and offloads the burden of worrying about injector control from the CPU. It's a closed-loop device using a current-sense resistor, so you just give it a simple on/off pulse and it figures out the rest. As a result of all this, lo-z injectors have much shorter lag times than hi-z injectors, meaning you have much better control over fuel delivery at very low duty cycles, such as when trying to idle a 1.8 engine on 750cc injectors. (Don't laugh, some folks here are doing precisely this.) Whatever you do, don't get taken in by the old trick of just putting 10 ohm resistors in series with lo-z injectors and then driving them with a conventional on/off signal. This is stupid, bad, wasteful, expensive, inefficient, and defeats the whole point of having bought lo-z injectors in the first place. I'm torn here... Traditionally, we start the ignition timer on the leading edge of CKP (75° BTDC) on the principle that this is the shortest amount of time that we can get between the trigger event and the actual ignition event. Less uncertainty. OTOH, as Jason and others have pointed out, crankshaft angular velocity is not a constant. The crankshaft accelerates during the first quarter revolution after a combustion event has been initiated, but then it starts to decelerate during the second quarter rev as the aforementioned combustion event concludes whilst another cylinder is simultaneously approaching the latter half of its compression cycle and increasingly opposing the movement of the crank. Would taking a sample at 5° BTDC be better? It means that you're free-running for longer on the timer, but will the crankshaft's velocity when at 5° be closer to its velocity at the time of the ignition event than it would be at 75°? Is there a physicist in the house? But... I'm stuck with what Mazda gave me, and with timing derived from both the rising and falling edge of the CKP, that should give enough accuracy for me... I'm not looking to do anything weird I just want to build an ECU with an Arduino :) |
Ok, I ran my code on a real Arduino today, and the Ignition timing pulse is never more than 0.5 degree late (and never early, as I'm erring on the side of late is better than early at low revs) at 1000RPM and never more than 1.5 degrees early at 8000RPM (with the timing advanced by 36 degrees as per the stock timing table. At 5500 RPM I'm never more than 0.1 of a degree early.
As this is alpha code, I think I can probably optimise it to get tighter timings. What degree of error do we expect/tolerate with respect to timing? -Edit- Just a quick note to say good call on getting timing from the rising and falling edges of the CKP, the 8000RPM timing would be horrific if I only used the falling edge! Also, Even though I don't have any injector time calculation in the code yet, the basic structure is built and only use about 4.5K of the AVR's 32K flash... plenty of space for some nice big lookup tables :) |
bloodline, good luck with your project, i hope it succeeds.
If / when you feel the code has reached a presentable stage, set up a project on sourceforge or something so others can contribute as well. |
Originally Posted by ctxspy
(Post 634444)
bloodline, good luck with your project, i hope it succeeds.
If / when you feel the code has reached a presentable stage, set up a project on sourceforge or something so others can contribute as well. I am happy to share the code and my mathematical models with anyone who wants to try this too, hopefully someone with experience interfacing with Real engine sensors and components. |
You should be better than 0.5* accuracy.
When you test the code, also test it with the crank simulator revving up and down at circa 5000 RPM per second squared. If you need the uC to look away for a bit of time, the best time to do it is right after a spark event, which makes it as far as possible from the next one. But you are starting to see why a Propeller might be better. ;) One cog would be dedicated to crank angle prediction, and spark. A Prop would need external ADC's tho. As for reading MAP, I can tell you for certain that you will need at least 50 ms updates, better yet, 25 ms. Any slower and you will have hesitation at low RPMs and at low throttle openings. And, if you only read it once and act on it (i.e. no software filtering), you MUST have analog filtering on it. Software filtering requires that you oversample. And the software filtering needs to be "Bessel" like - (decaying weighting) - simple running averages are not optimal, will suffer from aliasing artifacts and poor performance, and you can't just sample based on crank position (e.g. every 2 revs), because the sampling rate will change 10x from 700 to 7000 RPM. Far from optimal. The same will be true of all the other sensors. Re: TPS, IMO it *is* important to sample it quickly in order to do off-idle tip-in enrichment properly. |
Re: MAP filtering, look at my post re: my AEM.
The AEM has a software filter, but still, noise got through, until I added analog filtering: https://www.miataturbo.net/showthrea...ghlight=filter |
Originally Posted by JasonC SBB
(Post 634462)
You should be better than 0.5* accuracy.
I can see loads of room for improvement, so I will have another go... my Interrupt handler was too complex etc, trying to do too much. When you test the code, also test it with the crank simulator revving up and down at circa 5000 RPM per second squared. If you need the uC to look away for a bit of time, the best time to do it is right after a spark event. As a side note, I changed the Arduino's ADC clock to 1Mhz, which drops the acquisition time down to 21microseconds, which is a very nice sample rate of 56Khz :) Unfortunately this probably won't be compatible with an future boards. But you are starting to see why a Propeller might be better. ;) One cog would be dedicated to crank angle prediction, and spark. A prop would need external ADC's tho. |
I have been reading this page for some extra info:
http://www.diy-efi.org/efi332/equations/algorith.htm |
After running a few tests, and reading the EFI site, I decided to refactor my code and move to a deterministic polling based system to replace my interrupt based code... Turns out this is a much much better idea for running an engine with limited CPU resources :) an unfortunate side effect is that my code is now far less generic and is Miata NA specific, I was hoping to make it so the timer code would be a "plug in" module and could be easily reused for any other engine.
I want |
Does anyone here know what the longest duration injectors are ever left open? I need to know so I can decide if I schedule the close event before or after the CKP goes high. Thanks
|
Originally Posted by bloodline
(Post 634786)
Does anyone here know what the longest duration injectors are ever left open?
It's entirely possible (given inadequate injector sizing for the application) for the injectors to be on 100% of the time at very high RPM and load. Or 99%, or 98%.... |
Originally Posted by bloodline
(Post 634774)
After running a few tests, and reading the EFI site, I decided to refactor my code and move to a deterministic polling based system to replace my interrupt based code...
http://www.diyefi.org/forum/viewtopic.php?f=4&t=832 |
Originally Posted by Joe Perez
(Post 634840)
Seriously?
It's entirely possible (given inadequate injector sizing for the application) for the injectors to be on 100% of the time at very high RPM and load. Or 99%, or 98%.... Once I've got this code cleaned up, I will post it here, would that be of use to anyone? |
Originally Posted by JasonC SBB
(Post 634893)
|
Originally Posted by bloodline
(Post 634924)
Quite serious, I assure you.
Hmmm, it's not too much of a stretch to have a different injection algorithm at higher revs if need be. I'm my current cycle, there is plenty of time for injectors. Once I've got this code cleaned up, I will post it here, would that be of use to anyone? That seems like an overly complex way of going about it. |
Originally Posted by richyvrlimited
(Post 634973)
That seems like an overly complex way of going about it.
But I have found a few solutions that have bought me more CPU time... Notably, I decided to convert all degrees to 4096ths of a circle... that has allowed me to removed all division operations from my code, and replace them with shifts... I also found a way to speed up Analog conversions on the AVR and found that interrupts aren't actually a great idea in this context. Not to mention all the knowledge and advice provided by the forum members here! So all in all it has been been a very successful project so far :) |
Why not 1024th's of a circle? That's 1/3rd degree and good enough precision.
|
Originally Posted by JasonC SBB
(Post 635494)
Why not 1024th's of a circle? That's 1/3rd degree and good enough precision.
I considered using a 32bit value of 33554432, total over kill I know, but then 1 degree is 91.0 divisions, which is quite a nice value... But 32bit math on an 8bit chip is unpleasant :( If 4096 proves unworkable in a real situation, then I will try 1024 :) no doubt I will need to refine the design quite a bit as I test it. |
-Edit- looks like you might have a point, on paper at least... The error seems reduced using a lower division size... I might even try 512 per revolution :)
|
i'm also thinking about using an Arduino as an ECU, but for converting carb'ed engines to EFI (Toyota Pickup and LandCruiser).
would you be willing to share your arduino code so i can see what you have learned? if i make any headway, i'll be sure and send you everything i learn. it'd be so cool to have an open source, arduino based EFI/ECU system out there! the possibilities are amazing (pot adjustable air/fuel ratios, digital readouts from all sensors, switchable efficiency/power modes, etc etc). do you think the arduino is fast enough? thanks |
Originally Posted by josdavlar
(Post 637540)
i'm also thinking about using an Arduino as an ECU, but for converting carb'ed engines to EFI (Toyota Pickup and LandCruiser).
would you be willing to share your arduino code so i can see what you have learned? if i make any headway, i'll be sure and send you everything i learn. I will post my source code ASAP. Really what this project needs is someone with experience interfacing with real Automotive sensors and engine components to build the hardware. I can do the software as that is my day job :) it'd be so cool to have an open source, arduino based EFI/ECU system out there! the possibilities are amazing (pot adjustable air/fuel ratios, digital readouts from all sensors, switchable efficiency/power modes, etc etc). do you think the arduino is fast enough? thanks One thing I haven't got around to yet is worrying about the Emission controls, i.e O2 sensor/purge valves etc... they can come later :) The Mazda Miata Performance Handbook (Page 63) explains everything we need to implement them anyway. |
usually the hardware is some voltage value, AFAIK, unless there's an embedded controller that's spitting out actual data. i don't think that would be very common as it doesn't seem necessary in most cases.
i do think the O2 sensor plays an important role in air/fuel mix as it gives you near real-time values. the ECU adjusts the mix depending on how much O2 is left in the exhaust. i assume these values would be read by the arduino as a value between 0 and 1023. calibration is one thing i'm thinking is going to be tough. for example, if the O2 sensor is giving a value of 250, what does that mean? or perhaps there shouldn't be ANY or as little O2 as possible in the exhaust, so you're striving for a value of 0? also, how can you figure out the amount of fuel coming out of an injector for a given pulse? you need to know this figure to shoot for your ideal 14.7:1 air/fuel ratio - at least as a starting point. perhaps this is inferred via the O2 sensor? i'm pretty sure a good prototype will include pots and a good serial debug output that'll allow adjustments on the fly. as sweet spots become apparent in the real world you can firm up the code for your particular engine. am i anywhere near reality? |
Originally Posted by josdavlar
(Post 637595)
usually the hardware is some voltage value, AFAIK, unless there's an embedded controller that's spitting out actual data. i don't think that would be very common as it doesn't seem necessary in most cases.
i do think the O2 sensor plays an important role in air/fuel mix as it gives you near real-time values. the ECU adjusts the mix depending on how much O2 is left in the exhaust. i assume these values would be read by the arduino as a value between 0 and 1023. calibration is one thing i'm thinking is going to be tough. for example, if the O2 sensor is giving a value of 250, what does that mean? or perhaps there shouldn't be ANY or as little O2 as possible in the exhaust, so you're striving for a value of 0? also, how can you figure out the amount of fuel coming out of an injector for a given pulse? you need to know this figure to shoot for your ideal 14.7:1 air/fuel ratio - at least as a starting point. perhaps this is inferred via the O2 sensor? i'm pretty sure a good prototype will include pots and a good serial debug output that'll allow adjustments on the fly. as sweet spots become apparent in the real world you can firm up the code for your particular engine. am i anywhere near reality? |
do you know what kind of resources the serial port takes up? i wonder if it could affect the arduino's ability to crunch away?
i don't think this is an easy project, but i certainly don't think it's impossible. i think you've made some good points about the arduino's capabilities. it's better to forge ahead with a prototype than to fuss about niggly details. the important ones will present themselves. you're lucky in that you have a car known to work. i still need to fab an intake manifold, a throttle body and a high pressure fuel system! i'll also need to retrofit some crank and/or cam position sensors. i'm stoked to see your code! |
i can chime in briefly. Regarding sensors, they're usually analog values. You're looking for 0-5V on an AEM Uego o2 sensor for example, and there's already maps converting volts to AFR for the megasquirt. For the CLT and IAT sensors, there's a program called easytherm which will generate tables based on 3 input resistance-temperature values.
To josdavlar, i suggest you read up on the megasquirt ECU. It's already much more open than other ECUs and you can learn a lot from reading their support pages. One page, linked above i think, lists all the formulas they use. |
Originally Posted by josdavlar
(Post 637681)
do you know what kind of resources the serial port takes up? i wonder if it could affect the arduino's ability to crunch away?
i don't think this is an easy project, but i certainly don't think it's impossible. i think you've made some good points about the arduino's capabilities. it's better to forge ahead with a prototype than to fuss about niggly details. the important ones will present themselves. For me, this is a project about making an ECU for the lowest possible cost. I want to get the source code out there, and have someone try it out... I have tested it using a second microcontroller to generate simulated timing signals and it works fine... but a real engine is the test!! you're lucky in that you have a car known to work. i still need to fab an intake manifold, a throttle body and a high pressure fuel system! i'll also need to retrofit some crank and/or cam position sensors. i'm stoked to see your code! Here is the timing diagram: http://flic.kr/p/8FKPTk |
Ok, here is v0.4 of the code. This code has the old short Injector opening schedule. In v0.5 I have rewritten the code to allow for much longer opening times.
As you can also see I have hard coded this to use 10degrees BTDC, as I want to use this as the base to adjust the injector opening time and find out what a real engine needs at 1000. I have started with a default value of 8milliseconds opening time per injector, and would plan to adjust that until I get it right... but I need a real engine to test. I have tested this on a real Arduino, with a second board simulating an engine providing signals. As a simulation it works fine... Notice that the spark time is provided by a return value from a function, this is because the timing advance could change every phase. The injector time is global, as I might want to only adjust this less frequently in future. Code:
// MiataBrain1 ECU V0.4 |
How much is the hardware ($50) and what software are you using to tune stuff bloodline?
nvm I see still working on it, I"d be interested in testing later on, are you running the firing of the injectors and spark from a bench setup miata CAS yet? |
Originally Posted by Techsalvager
(Post 637866)
How much is the hardware ($50) and what software are you using to tune stuff bloodline?
nvm I see still working on it, I"d be interested in testing later on, are you running the firing of the injectors and spark from a bench setup miata CAS yet? Here is a video of my ECU outputs: The output of my ECU project, the top row of LEDs are the injector signals. The bottom row of LEDs are the spark signals. The CAS timing simulator is running at 160RPM so that it is slow enough to see :) |
My e-penis is hard from all the nerdery. I <3 mcus.
|
I don't know much about the arduino programming language, so here's a couple stupid questions.
Is it hard to create two dimensional arrays? If not, it would be really impressive if you could add the two basic tables (spark advance and VE) for lookup for ignition timing and pulsewidth. From the megamanual, here's the formula to calculate pulsewidth: PW = REQ_FUEL * MAP/100 * VE/100 * GammaE/100 + Inj Open Time VE being the RPMxMAP table, gammae can be ignored, "inj open time" is stored in firmware, and req_fuel is stored in firmware. Another (probably a stupid one) -- does the arduino have the ability to fire the injectors and the COPs/ignitor? Tomaj |
Originally Posted by ctxspy
(Post 637901)
I don't know much about the arduino programming language, so here's a couple stupid questions.
Is it hard to create two dimensional arrays? If not, it would be really impressive if you could add the two basic tables (spark advance and VE) for lookup for ignition timing and pulsewidth. From the megamanual, here's the formula to calculate pulsewidth: PW = REQ_FUEL * MAP/100 * VE/100 * GammaE/100 + Inj Open Time VE being the RPMxMAP table, gammae can be ignored, "inj open time" is stored in firmware, and req_fuel is stored in firmware. If I am correct, these value can only be known with access to real data, from a working engine. Another (probably a stupid one) -- does the arduino have the ability to fire the injectors and the COPs/ignitor? So, yes :) |
For those interested I built my own CAS, Here is the disk, I cut out the black areas. Mounted two LEDs and two LDRs... one to monitor the inner ring (the Crank Position), the other to monitor the outer ring (The Cam Position).
http://www.cutiemish.com/photo.JPG |
The Arduino just uses C++, so 2D arrays are simple :) I already have the spark advance sorted out (not included in my example since I really want someone to test it at idle only) using the standard timings found in the original ECU. Not sure how to parse that formula, I assume "required fuel" is given by the throttle position, (MAP/100) is the coefficient of barometric pressure in the manifold as a percentage... The original car doesn't have a sensor for this. (VE/100) would appear to give us our loading value, so we know how much work the engine is doing... I don't know what GammaE is... and "Inj open time" is the time taken for the injector to go from fully closed to fully open... The MAP value is absolute manifold air pressure, in kPa, so this is using percentage of barometric pressure (i think). I'm pretty sure your ECU would mostly be used by people with turbos, so the MAP is needed. The VE value is looked up in the VE table for any given RPM & MAP . GammaE is basically your "sum of adjustments" (Air temperature, barometric pressure, coolant temp, warmup, whatever). If I am correct, these value can only be known with access to real data, from a working engine. If you watch my little video, you can see the injectors (top row of LEDs) firing sequentially, and the ignitors firing in pairs. The sequence is correct, with the TDCs going Cylinder 1, Cylinder 3, Cylinder 4, Cylinder 2 |
Originally Posted by ctxspy
(Post 638701)
I understand your position but at the same time showing a more advanced capability could build excitement around your project.
In theory, the code I posted should "work", and at least hold the engine at an idle... Only once I can confirm that, can I really think about adding all the cool stuff. REQ_FUEL is a constant calculated based on injector size, engine size, etc. (details on that site from above). It allows you to 'abstract' your fuel table instead of using milliseconds of injector time. The MAP value is absolute manifold air pressure, in kPa, so this is using percentage of barometric pressure (i think). I'm pretty sure your ECU would mostly be used by people with turbos, so the MAP is needed. The VE value is looked up in the VE table for any given RPM & MAP . GammaE is basically your "sum of adjustments" (Air temperature, barometric pressure, coolant temp, warmup, whatever). There's no reason the other arduino you're testing with couldn't supply some values for RPM, MAP, air temp, etc. I saw that video, looks good. I was questioning more of the actual juice necessary to operate the injectors and fire the ignition. Not sure what kind of power is required for that. Like this: http://www.vems.hu/files/Wiring/DRFlyback.jpg |
Remove the diode and use 30V MOSFETs that are "avalanche rated".
You don't want to clamp the injector votlage when you turn it off, because that will slow down its closing time. |
Originally Posted by bloodline
(Post 638665)
Not sure how to parse that formula, I assume "required fuel" is given by the throttle position, (MAP/100) is the coefficient of barometric pressure in the manifold as a percentage... The original car doesn't have a sensor for this. (VE/100) would appear to give us our loading value, so we know how much work the engine is doing...
Req_Fuel, to be precise, is the theoretical duration of fuel flow required for one injector to achieve perfectly stoichiometric combustion on one cylinder for one cycle, assuming 100% volumetric efficiency at standard temperature and pressure. In layman's terms, it's the one value you can change to scale everything else from one injector size to another. You could easily eliminate Req_Fuel from the calculation (just assume it to always be 1) and simply tune the VE table appropriately. TPS doesn't factor into the primary fuel calculation unless you are running in Alpha-N mode. (You're not.) and "Inj open time" is the time taken for the injector to go from fully closed to fully open... If I am correct, these value can only be known with access to real data, from a working engine. http://img40.imagefra.me/img/img40/7...am_f66a5d8.gif In that config, Req_Fuel is 13.4, and let's say that injector lag is 1ms. So, if we're in a cell where MAP = 100, and VE is 100 kPa, and GammaE is 1, and we assume that each injector squirts only once per engine cycle, then each injector channel will be energized for 14.4 ms for each cycle. (13.4 * 1[MAP] * 1[VE] * 1[GammaE]) + 1 If we're in a cell where VE = 50, then (13.4 * 1 * .5 * 1) + 1 = 7.7 ms If VE is 50 and MAP = 50, then (13.4 * .5 * .5 * 1) + 1 = 4.35 ms At least, I think so. It's been a while since I've slept, so if it turns out I'm wrong, then just ignore me. :D |
Originally Posted by Joe Perez
(Post 638867)
I'll just elaborate a bit on ctxspy's rather good answer.
Req_Fuel, to be precise, is the theoretical duration of fuel flow required for one injector to achieve perfectly stoichiometric combustion on one cylinder for one cycle, assuming 100% volumetric efficiency at standard temperature and pressure. In layman's terms, it's the one value you can change to scale everything else from one injector size to another. You could easily eliminate Req_Fuel from the calculation (just assume it to always be 1) and simply tune the VE table appropriately. TPS doesn't factor into the primary fuel calculation unless you are running in Alpha-N mode. (You're not.) ... minus the amount of time for the injector to go from fully open to fully closed. Here's a sample table of VE values, taken from DIY's basemap for a 1.6 engine. The numbers in it are not literally the true volumetric efficiencies of the engine (this is the table in which we apply lots of fudge factors, such as scaling for different desired AFRs) but these are the numbers that work for a Megasquirt following the rules laid out in the formula earlier. http://img40.imagefra.me/img/img40/7...am_f66a5d8.gif In that config, Req_Fuel is 13.4, and let's say that injector lag is 1ms. So, if we're in a cell where MAP = 100, and VE is 100 kPa, and GammaE is 1, and we assume that each injector squirts only once per engine cycle, then each injector channel will be energized for 14.4 ms for each cycle. (13.4 * 1[MAP] * 1[VE] * 1[GammaE]) + 1 If we're in a cell where VE = 50, then (13.4 * 1 * .5 * 1) + 1 = 7.7 ms If VE is 50 and MAP = 50, then (13.4 * .5 * .5 * 1) + 1 = 4.35 ms At least, I think so. It's been a while since I've slept, so if it turns out I'm wrong, then just ignore me. :D |
Originally Posted by bloodline
(Post 638679)
For those interested I built my own CAS, Here is the disk, I cut out the black areas. Mounted two LEDs and two LDRs... one to monitor the inner ring (the Crank Position), the other to monitor the outer ring (The Cam Position).
http://www.cutiemish.com/photo.JPG Looks a little off compared to the 1.6 cas off course thats probably fixiable but just giving you a view of the 1.6 disc |
Originally Posted by Techsalvager
(Post 638951)
http://users.forthnet.gr/ath/twikico...a16CASdisk.jpg
Looks a little off compared to the 1.6 cas off course thats probably fixiable but just giving you a view of the 1.6 disc Thank you for posting that, I mst say ou had me scared for a moment :) |
A new Disk, this one has the crank signal inverted and moved to the outer edge:
http://www.cutiemish.com/casdisc.jpg |
After quite a bit of testing my code seems to exhibit instability at random RPMs... Has anyone else noticed this, has anyonenelse tested my code?
I will profile my code asap, and see if I can find the issue... Stupid work getting in the way at the moment :( |
Ok, my ECU code is fine. It was my simulator code that was wrong :)
|
good to hear you're still working on it. if you ship me your arduino i'll test it on my car ;-)
|
Originally Posted by ctxspy
(Post 640386)
good to hear you're still working on it. if you ship me your arduino i'll test it on my car ;-)
For a laugh, I ported my code to my mBed board... Wow, this project would be much easier on a super fast mcu ;) |
will the uno do what is needed as well and have all the outputs? I may buy one and hook it up to bench setup with a 1.6 cas and ignitor\coils\spark plugs
|
Originally Posted by Techsalvager
(Post 640515)
will the uno do what is needed as well and have all the outputs? I may buy one and hook it up to bench setup with a 1.6 cas and ignitor\coils\spark plugs
It has 32k of code memory (more than enough for our needs, my barebones code uses about 4k) and 2k of RAM which is adequate. It runs at 16Mhz, with 1 instruction per cycle, so we can brute force a lot of stuff. I/O pins 2 and 3 can trigger interrupts... Though I've opted not to use interrupts with my software design. The I/O system is is all 5volt so spot on for the Mazda electronic system. The more powerful mBed device is all 3.3volt so would be a bit more involved to interface with the 5volt electrical system of the mx5... I would say it's a fair bit better than the 6800 in the stock ECU. My code is hardcoded to the mk1 (NA) CAS. If you look at my code, you can see the input/output pins are configurable, so the software is flexible WRT hardware if need be. -Edit- If you do get one, then let me know, and I'll send you my latest code. |
I found a dump of the '94 1.6 ECU ROM here:
http://forum.miata.net/vb/showpost.p...&postcount=332 I've been working through it to see if there is anything I can learn. It seems pretty straight forward and I'll build my timing and fuelling maps based on that data, which should give a good safe starting point. I've also started thinking about a Laptop App to allow ECU parameter adjustment while the ECU is running (MacBook only for the time being, apologies)... that should be quite useful. |
good stuff bloodline
|
if you share your spec for communication i can write something in Java or C#
|
Originally Posted by ctxspy
(Post 641139)
if you share your spec for communication i can write something in Java or C#
|
I popped into my local electronics store to pick up a couple of potentiometers, so I can test my analog code, and bought a piazo transducer... After a quick test, it looks like it would be quite easy to add a knock sensor to this project, would have to run extra wiring from the engine bay though as the existing loom lacks any spare wires :(
|
I don't know if any one is still interested, but I have moved my injector code over to an interrupt based system, (the old system had a limit to the maximum injector open time) and also the coil dwell time is now adjustable. I will be releasing this new code soon. The project is now at version 0.5 :)
I hope someone will find it useful. |
I'm still interested. I don't know that i'll use it on my car presently but it's something i'll follow and help where i can.
If i may humbly suggest -- slow down on your version numbers, as 1.0 is usually reserved for a working product :P |
depends on how someone does their versioning.
|
Originally Posted by ctxspy
(Post 643058)
I'm still interested. I don't know that i'll use it on my car presently but it's something i'll follow and help where i can.
If i may humbly suggest -- slow down on your version numbers, as 1.0 is usually reserved for a working product :P It's my system... :laugh: |
got it. Let me know when you want to start talking about a configuration interface.
|
still watching this thread!
could you clarify what the CAS is and what that black and white disk is? |
Originally Posted by josdavlar
(Post 643927)
still watching this thread!
could you clarify what the CAS is and what that black and white disk is? having read your other posts (all on this thread) I can only imagine you're a non-miata guy and you joined this forum because of this thread. That said, please spend 5 minutes before posting questions to do basic research. |
| All times are GMT -4. The time now is 08:24 PM. |
© 2024 MH Sub I, LLC dba Internet Brands