Which came first 2-stroke or 4-stroke?

We all know this and it has been told to us again and again...
4-stroke engines are better than 2-stroke engines. They are more efficient, less polluting etc. Also we know that 2 stroke engines make more power ( Because they have a power stroke every crank cycle!!). However, did any of you think why was there a 2-stroke engine in the first place if 4-stroke engines are so good.
Infact i just wikied this

Invention of the two-stroke cycle is attributed to Scottish engineer Dugald Clerk who in 1881 patented his design, his engine having a separate charging cylinder.

Now also wiki says

The four-stroke engine was first patented by Eugenio Barsanti and Felice Matteucci in 1854, followed by a first prototype in 1860. It was also conceptualized by French engineer, Alphonse Beau de Rochas in 1862.

As it is clear 1854 is before 1881, why did some one build an apparently less efficient version of the engine?
I believe the answer is as follows

• The 2-stroke engine is much lighter than its 4-stroke counterpart. It has no valves (intake or exhaust) hence no Camshafts & Cams. This also translates to lesser needs of lubrication. You can just add the lubricant to your fuel and you should be good.
• They could be constructed in lesser space because of lesser number of components, making them a good option for lawn mowers, power saw's etc.
  

Due to the above factors it made the 2-stoke engines much cheaper than the 4-stroke versions. Modern 2-stroke engines have started employing Gasoline direct Injection.
The 2-stroke has come a long way and still remain favourites among hard core bikers who drool at the power produced by these machines ( Remember the Rx-100). They have their issues when it comes to thermal handling ( they get heated faster and need to be cooled more) but that can be handled by having bigger engine cooling fins ( Greater the surface area of the fins better cooling!!). So next time you ride a RX...remember that they came after the 4-stroke versions.

Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Fuel Injection - Evolution Journey-II

This is a fully automotive powertrain article.
Disclaimer: I am a novice in this area. If experts read this kindly correct...

Q: What are the different fuel injection methods used?
Fuel injection systems evolved over the years from being a simple Manifold injection to DI ( Direct injection). The injection of the fuel into the Intake Manifold based on the Air Mass that is currently sucked into the cylinder is controlled either electronically or by mechanical methods. This is typically a function of the engine load. The engine load can roughly be determined by the throttle opening. The terms "Full-Load" ( i.e. Throttle valve is fully open) and "Idle" (i.e. when the Throttle valve is closed & the vehicle is stationary) are very frequently used in the discussions further.
After the SPFI ( Single point fuel injection) where the fuel was sprayed into the manifold the next thing that became very popular was multi point fule injection (MPFI). Here multiple injectors were placed at suitable positions in the intake manifold to get finer control over the air-fuel mixture. Also having multiple injectors ensured that the injector closest to the cylinder going into suction stroke could be activated. In some cases this is called Port Fuel Injection (PFI). This provided also the following benefits:

• Fuel going into each cylinder could be precicely controlled.
• Air & fuel would get mixed just before inlet into the cylinder. This ensured that the atomised fuel did not have condensation problems. i.e. in manifold injection with single injector the air-fuel mixture when suddenly expanded in the cylinder under cold start conditions the fuel would condense & form larger particles inside the cylinder which led to higher emissions

The MPFI injection systems came in two variants, though this is not really something great !!..

• Batch Fired : In this all the injectors for one bank of cylinders where activated in one shot. i.e. for a 4 cylinder engine, injectors for cylinder 1 & 4 were activated together similarly 2 &3.
• Sequentially fired: Here the injectors where activated sequentially based on which cylinder was going into suction stroke.

Finally came the Direct injection. The direction injection opened up new domains of controlling the air fuel mixture because now only air would enter the cylinder and it could be the ECU that would control the fuel being injected into the cylinder. This ensured that by injecting at different points inside the cylinder & by different cylinder head profile one would achive higher spread of the atomized fuel. This lead to better flame front propagation, ensuring higher power output.
Why did we not go for Direct Injection to start with ?
The manufacturing processes in earlier days did not provide us with methods to have injectors that could bear the very high pressures generated inside the cylinder. Also, the fuel injector tip has to bear extreme temperatures which are generated inside the cylinder. Also, the pump which pumps fuel into the injector needs to generate very high pressures because if fuel is injected in the later stages of compression ( like it is done in Stratified mode of operation). The injector nozzel design also has undergone many design changes to ensure that a extremly fine spray with precise control on droplet size could be created.

Powered by ScribeFire.

Inlining code - Coding Myth 2

This post is regarding the inline keyword.
Very often we learn C & C++ together and end up mixing one language with the other. I learnt this the hard way when i found out in some debate that the "inline" keyword doesn't belong to the C language.....Boohooo!!..
Inline keyword natively belongs to C++.  It serves the purpose of just ensuring that the function is pasted inline instead of having a call to the function at every instance of the function call.
It was not a part of C. In "C" we achive similar functionality by using what are termed as "Function Like Macro's".
E.g.
#define Max(a,b)  ((a)>(b)?(a):(b))
The funciton like macros have a major disadvantage over Inline functions and that is the blindness to the compiler.
#define macro's are processed by what is known as the "C Preprocessor". The preprocessor looks for the macros and does a macro pasting operation. Which means that where ever in the above example Max is used the equivalent code is pasted.
E.g
y = Max(5,6); is equivalent to y = ((5)>(6)?(5):(6));
Then what is this blindness funda?
Well if iwrote this code
int *ptr;
y = Max(ptr,'5').
Then even this would work as for the Macro-Processor. Infact in this particular example even the compiler will not complain. However, if this was a inline function then the compiler would have been flag an error.  So it is easy to see that the inline key word has benifits over the #define macro.
Now some interesting stuff

• - Did you know that the inline keyword is just a request to the compiler. The compiler might choose to ignore you fully and would just make the function a normal function if it feels that by making it inline it is losing out on optimization.This is in contrast with #define function like macro's which are outside of the compiler's control.
  

• - Modern C compilers provide you various methods of inlining function by compiler extensions. E.g some compilers provide pragma's

#pragma InlineStart
void Inlinefunction(void)
#pragma InlineEnd
or things like
@inline void Inlinefunction(void)

• Inlining is very useful to ensure modularity & keep your code clean. However, In "C" if this was natively available then we embedded users would not have resorted to function like macro's.
• Evils of the keyword "inline".....Well it is difficult to debug your inline function because there is no call to the function and also it is not really visible to your debugger:-(.
  

Now that we have some idea of the keyword "Inline", you can try to check out the statements made above using our good old GCC compiler with "-S" option and have a look at the generated assembly code.
Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Fuel Injection - Evolution Journey

This is a fully automotive powertrain article.
Disclaimer: I am a novice in this area. If experts read this kindly correct...

Q: Why & How did FI ( Fuel Injection) systems evolve?
For a long time carburetor based engines dominated the automotive world. The were good and could make your car run smoothly. However, increasing emission norms & better systems being used by the air planes eventually led to their extinction  in the four-wheeler world ( Though my XCD-135 bike still uses a carburetor for managing the air-fuel mixture). The major things that led to the death of carburetor engines are :

• Too many compensations where needed making the design look like spaghetti code. The were compensations for idling, for cold start among other things.
• Carburetor icing had plagued high altitude flying machines, this led to development of what we today know as EFI systems ( Electronic Fuel Injection). They started off as SPFI  (Single Point Fuel Injection) & then evolved into MPFI ( Multi Point Fuel Injection)

With the new FI systems it was necessary to have electronics to control the fuel injection. This was done by having solenoid controlled fuel injectors. These injectors could be actuated by providing what is generally called the "Fuel Pulse" and the timing & the duration (pulse width) of the pulse could control the amount of fuel sprayed into the manifold. The Advantages of  the new Fuel Injection system ( Now of course its quite old) were :

• Better efficiency due to the fact that the fuel-air mixture could be made LEAN or RICH ( not fat for god sake !!).
  
• No carburetor icing wherever it was applicable. Just in case you are wondering what is Carburetor icing, it is the basically formation of ice in the carb's venturi due to condensation of humid cold air (due to further drop in the venturi). This is often accompanied re-conversion of the fuel from its atomized format to more liquid format.
• EFI systems will also help in reduction of NOx emissions due to which it is better complaince with emission norms is possible.  

The story is more compilicated than what has happened so far because soon a need was felt to control the ignition, Cams, valves and what not. There was also emergence of the EGR concept ( which was present even the carb engine days). The compensations & corrections that were needed to the various parameters based on vehicle parameters like Engine RPM, AC ( air conditioning), vehicle speed  ABS etc has transformed the electronic control systems into a work of art.
In the next post on this topic, I will be going into the various systems that influence a engine & how the EMS ( Engine management system) handles them.
more on....
carb icing
EFI


Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

When Size does matter - Coding Myth 1

Again i am slow in updating this blog and this time it is really because I was busy with some GUI building activity on Matlab. I will write more about in another post. However, today the topic is more about "C" coding myths.

Some dudes I have met write really write complicated code like the one below stating that it will be more efficient. Some how they seem to feel that compact code ( in terms of number of lines & characters used) translates directly into lesser code volume in the microcontroller. I just tried this....

Code:

unsigned char alt2(void)
{
    unsigned char var=10;
    unsigned char output;
    if(var==1)
        output=3;
    else if(var==2)
        output = 2;
    else
        output =1;
    return output;       
}
unsigned char Alt(void)
{
    unsigned char var= 10;
    unsigned char output;
    output = (var==1)?(3):((var==2)?(2):(1));
    return output;
}
void main(void)
{
    int x;
    x = alt();
    x = alt2();
}
Now on compiling this with avr-gcc with -S option you should be able to get the assembly code output also. Let us compare the functions Alt and Alt2 which have same functionalities.
alt2:
    push r29
    push r28
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 2 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    brne .L2
    ldi r24,lo8(3)
    std Y+1,r24
    rjmp .L3
.L2:
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L4
    ldi r24,lo8(2)
    std Y+1,r24
    rjmp .L3
.L4:
    ldi r24,lo8(1)
    std Y+1,r24
.L3:
    ldd r24,Y+1
/* epilogue start */
Alt2 takes a stack frame of 2 bytes and the code is readable to a great extent. I am sure it is more maintainable compared to Alt. However, Alt generates a stack frame of 4 bytes.
Alt:
    push r29
    push r28
    rcall .
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    breq .L7
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L8
    ldi r24,lo8(2)
    std Y+3,r24
    rjmp .L9
.L8:
    ldi r24,lo8(1)
    std Y+3,r24
.L9:
    ldd r24,Y+3
    std Y+4,r24
    rjmp .L10
.L7:
    ldi r24,lo8(3)
    std Y+4,r24
.L10:
    ldd r24,Y+4
    std Y+1,r24
    ldd r24,Y+1

We see that now the stack frame is 4 bytes & to  add to the woes the code is not so much readable as well.
Thus, we break a myth that complicated & compressed "C" files give compressed code. More often that not modern compilers are clever enough to do everything that is needed for optimisation. So please spare yourself the troubel and let the compiler do its job.
However, that doesn't mean that we should write inefficient code. What it means is that -  "Dont think you have optimized the code by just changing some "if" statements to "ternary"  operators. It is more than that and quite usually compiler dependent". The best way to optimize is to read the compiler manual and try to understand the compiler and its capability. Then you can use tricks in "C" to optimize the code.
 

Powered by ScribeFire.