Auto Transmission - I

With the advent of technology man has always asked for better systems to lower his efforts in doing things. The same story goes for Transmissions. Manual transmission served the purpose very well. However, soon the customer demands became higher and he wanted a system that could change gears on its own. No one wanted the clutch anymore!! Well atleast not the folks who always tended to over the engine by downshifting too early or lead the vehicle to stall by upshifting too early. This lead designers to come up with a system in which the clutch pedal could be totally eliminated. There were lot of solutions and some have been described here. Unfortunately, i dont know the order of their evolution but guess that that is not really all that interesting...
Lets take the case of the simple Hero puch or the TVS 50.....Can we call it an automatic transmission....?
Not really...however to some extent yes.
How does based on throttle the vehicle start moving?
This is because of a clutch that engages as the RPM increases. Such a clutch is called Centrifugal Clutch. Normally the clutch is disengaged. Which means that no power from the engine will be fed to the chain drive. However as the RPM increases a certain threshold the clutch engages. With the clutch engaging the power is transferred to the wheels. This is a very basic of how we can eliminate the manual clutch ( our initial aim ....). As it is clear that the centrifugal clutch will wear out with time and that means RPM points at which the power will get transferred to you chain drive will vary with time. The second disadvantage is that this method cannot transfer huge amount of torque from the engine shaft to the output shaft. I am not really using the term Transmission shaft because this is not a "Transmisison" in classical sense.
What are the other methods?
How about Kinetic Honda that has been ruling the roads since i was a kid?
Well a Kinetic Honda uses a different mechanism. It uses what is known as a belt drive...( atleast that is what i was told. I am not 100% sure!!). This is fed to a Stepped pulley or Coned Pulley. This coned pulley will be able to provided different Pulley Ratios based on which point of the pulley is used to Tap the output. A the most broad end of the pulley the Torque transmission will be less and a the thinnest end of the pulley the Torque transmission maximum. Centrifugal clutch is still used here.
Does that mean CVT ( The stuff we talk ed about...Continuous Variable Transmission) is a cheap and dirty technology?
No absolutely not. Like any other technology based on how much complexity is added one can make the system very sophisticated. The commonly used CVT's in bikes like Honda Activa, Honda Dio, Kinetec etc are fairly simple. However, some really complicated stuff from Audi can be found here and remember the core is still same....a coned pulley...

After taking care of these two aspects...i.e. some kind of autoclutch and a automatically shifting gearbox the other biggest challenge was to ensure that high amounts of torques are transmitted through the shafts. When you talk of cars like Mercedes, BMW's and high end Maybach's Torque can touch much more than 100 Nm's. 12 cylinders V's could not be "Auto-Transmitted" using a simple or complicated CVT...

Something new was needed...and that will be apart of the next blog ofcourse :P

Glossary of EMS terms -part 1

This article just introduces a few terms that are very frequently used when we talk about Powertrain. I would say this is just some kind of a glossary of terms

Lean & Rich Mixtures: Both terms talk about air-fuel ratio. A Lean mixture is one in which the air (oxygen) is more than what is needed to burn the fuel. Obviously Rich mixture is the other way round ( though opposite of lean is fat!!). The stoichiometric ratio or the right ratio is about 14.7:1 ( for pure octane). Which means, to burn 1 part of fuel we would need about fifteen parts of air. Note, that when i talk of air it is actually the oxygen that i am really interested. One very big misconception is that all 14.7:1 is the universal ratio which is false because this depends on the fuel ( its octane number + if there are any additives like anti-knock).

Lambda : For a long time i could not understand this value and people told me all kinds of things. for starters "λ" is not the air-fuel ratio but it is a measure of the air-fuel ratio. The best of understanding λ is that it is "Excess air factor". So if λ is 1 that means there is no extra air and we are running at stoich ratio. If λ is greater than 1 that means we are running Lean because we have extra air in the mixture. Similarly, λ <1 means that our mixture is rich, there is less air than needed to burn the entire volume of fuel that we have.

Lambda Sensor: This is also called O2 sensor. Again this was a very confusing term for me ( still is!!). Why do we call this λ sensor? what does it measure? &Lamda sensor is actually a 0xygen sensor. This give out a voltage output based on the oxygen content in the stream. There is a platinum probe one side of which is exposed to exhaust gases while the other side is exposed to atmospheric gases. This works pretty much on the same principle as a electrolytic cell. The voltage output is used by the ECU to do other calculations about which we shall talk in future. In modern vehicle i would expect atleast 2 such sensors.

58x Signal: This is basically the term that has evolved for the cranktooth signal. For ECU controlled engines, with individual cylinder control it is necessary to know when to fire which cylinder and for this it should know which cylinder is at TDC and which at BDC. This information is available to the ECU via a toothed wheel which is connect to the crankrod of the engine. For a lot of reasons, including ease of software computations, 60 tooth where chose on the wheel with 2 teeth missing. The missing teeth helps the ECU recognize where the cylinders are. Some manufacturers are more comfortable using the 28x signal. i.e 30 teeth with 2 teeth missing.

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

Powered by ScribeFire.

Throughput funda's

I have been quite inconsistent in updating the information presented on this blog. The one things that discourages me like any other new blogger is that very little traffic is seen here and since this is a technical blog, unless i get feedback it is difficult for me to judge if something is good or bad. However, for now i have considered that no feedback is negative feedback. Nevertheless i continue to write.
What is Throughput...This is the weeks question.
Wordweb tells me

Output relative to input; the amount passing through a system from input to output (especially of a computer program over a period of time)

The Throughput that i am talking is the one that embedded engineers often talk about. In simple terms this value is a measure of the CPU load under the worst conditions. What could be the worst conditions? These are basically situations which demand more processing power. For example, Image Stabilization, Red Eye Detection, Smile Detection, Ambient light detection along with Click detection or auto timer ( and image post processing) in a Camera perhaps put a great deal of performance demands on the CPU in a Digital camera and this also determines it worst case performance.
Unfortunately like many other engineering terms a higher value of throughput means that your system is more loaded. Often under some conditions the throughput reaches 100% in systems which means the CPU has almost no idle time and is being utilized all the time to its maximum capacity.
If i look at it from an EMS perspective then startup is the when there is very high CPU loads that are encountered. In an OS based system there are methods to determine for how much time the CPU is free. Usually, some background tasks which are not necessary to be done all the time are done in this free time. ( Example, CRC calculation or RAM Checks etc). In simple scheduler based systems the throughput is just the time remaining in the baseloop after all the tasks have been finished. One more parameter that influences the throughput to a great extent is the Interrupt Rate. A very high interrupt rate will ensure that the CPU loses a lot of time in context switches which are really an overhead and do not contribute in anyway to the functionality of the system.
[ This was my understanding of Throughput. After looking into wiki i think the origin of is term comes from the CPU bandwidth utilization. The term is primarily used for parametrization of Communication channel bandwidths]

How Do we ensure that we never reach 100% throughput?

• Plan your interrupts and their sources well. You should know the worst case rate of an interrupt beforehand. Example, the Door lock engage interrupt cannot come at say more than 1-2 times a second ( Due to the inertia of the lock).
• Write your code with throughput in mind. E.g if possible use binary search in place of linear search. Use macros instead of functions judiciously
• Overuns should be detected in software using some special variables or debug variables. Over-Runs occurs when the throughput goes more than 100%. Which means that you have asked the CPU to more than it is capable of handling in the given time. 

This is very brief and windowed perspective of Throughput. If you have some other inputs as to how this is related to your domain then do put a few lines of comments.
 Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Engine basics - Knocking

This post talks a bit about a concept called "Knocking" which is very common in Spark Ignition Engines having very high compression ratio.
The question we need to answer first is what is Knocking?
"Knocking" is a metallic pinging sound that is caused inside the engine cylinder & leads to high intensity vibrations in the Engine block ( usually causing metal fatigue in the cylinder walls). If the engine knocks for very long duration then this might have serious impact on the usability of the engine and on the engine life.
What causes "Knocking"?
Flame front:
The power inside the cylinder which is generated when a spark ignites the air-fuel mixture leading to a flame front. The flame front is a high velocity pressure wave that travels, after originating near the spark plug, downwards to push the piston head and ensure that our engine keeps running.
Now, what happens is that based on the fuel quality among many other factors there are certain spots inside the cylinder with some carbon deposits.If the cylinder temperature keeps rising due to ignitions then at some point of time these hot spots reach a temperature where they are capable to ignite the air fuel mixture or the yet unburnt gases (also called End gas). Simply put there is sufficient heat accumulation at certain points that these act as potential spark plugs.
The Problem:
This causes a problem because we do not have any control over these spontaneously created spark plugs ( so to say). This means that they can ignite the end gas at any point of time. In homogeneous operation of engine ( more about this mode in future posts), the mixture is fairly rich and these hot spots have energy sufficient to create a ignition of the air-fuel mixture.  This phenomenon  is often known as "Detonation".This ignition causes a pressure wave to travel from the spot towards the periphery. This Flame-Front if collides with the flame front travelling from the spark plug will result  in wo very high pressure waves to bang into each other. This leads to very high pressure peaks which put extreme amounts of stress on the cylinder walls. Continuous Knocking might lead to permanent stresses getting formed in the cylinder walls & the piston head which eventually will lead to their failure.
How to Avoid it ?
A few years back when "leaded Petrol" used to rule the market the folks added something known as Anti-Knock in the petrol to ensure that it did not knock. This however, lead to higher amount of particulate matter in the exhaust and also was not good for the cylinder walls.The anti knock was a Lead compound which i cannot remember at this point of time.
These days we use more of "Unleaded Petrol" and there has to be  different mechanism to control the "Knocking". This is done these days by ensuring that the engine temperature doesn't reach very high ( then there is lesser chance of hot spots getting created). One of the methods employed to do this is EGR. Exhaust Gas Recirculation, ensures that he temperature of the engine come down apart from having benefits like enhanced fuel efficiency and reduced NOx in the exhaust. However, that is a different topic and will be dealt a little later. The other method used in conjunction with the EGR is spark retard. Spark retard will ensure that you ignite the air-fuel mixture late enough that there will be no pressure peaks. When we do not have pressure peaks the chances of knocking are lesser.
Finally, use of high octane fuel will result in better combustion of the fuel and lesser hot spot contribution because of poor fuel quality. The reduction of hot-spots will result in reduced Knocking even at higher engine temperatures.
Some links that give more info on how it is detected etc
[1]

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

Powered by ScribeFire.

Const Keyword - Coding Myth 3

This post talks about the "C" keyword "const". It is very often thought that making a variable "const" ensures that it gets placed in the non-volatile memory (ROM or flash). But how true is this?

Well to start with w.r.t the ansi "C" compiler, the "const" keyword just tells the compiler that the user doesn't intend to modify the variable.
E.g.
           const unsigned int Gctrl_NoOfGears= 10;
so if i try to do this
           Gctrl_NoOfGears +=1;
I can either except a warning or an error. something like this
error: assignment of read-only variable `Gctrl_NoOfGears'
However, does this warrant me that the variable is now placed inside the memory in an non-volatile area.
Well, the answer is it is compiler (settings) dependent.
Why?
Most embedded compilers are very smart and automatically place the constants in the ROM/ flash area. However, some times the flash or ROM is used only as program memory and NOT as data memory. In which case there is no way (directly) that the compiler can place this in the program memory. Also In these processors the program memory is not directly accesible because the program & data are stored in differrent memory location & have different busses to access.  In such processors writing

const char DisplayStr[] = "Welcome";

will not cause DisplayStr to go into the ROM area.
You will have to do this via some compiler pragma's like

#pragma section start ROM
const char DisplayStr[] = "Welcome";
#pragma section end ROM

to make the compiler understand that it has to place the value in ROM & not in the RAM area.
Do I have to worry?
As a novice or some one programming for a simple system NO. However, when you are running low on resources and for various other reasons it makes sense to have a look at what the compilers is doing when you say "const". I repeat MOST compilers are clever enough to put the data into the ROM automatically.
The best practice is always to have a glance into the map file to ensure that you have everything at the right places.
Also, in one of the future posts i will be talking about another usages of const and how some constants are present even without your knowledge ( also little talk about const volatile...the common question in any interview on "C").

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

Previous coding myths here {1} ,{2}

Powered by ScribeFire.

Some fun with matlab

I have not been able to do a lot of blogging on this site of late. Procrastination is the reason. Also, I was a bit busy with my project-work ( or the lack of it!!). Here I write about a small script i wrote to convert from mat files to csv files. I searched a lot for existing solutions but alas none was available though csv to mat converters exit in bulk.  While i wrote the script i realized the reason for non existance of such a script.
In Matlab you can store different types of information into a Mat file and some of it might not be easy to represent directly in a CSV file. for example structures cannot logically be put in a CSV file but arrays are easy to convert into csv.
So i wrote a script which can convert mat to csv but with a restriction. The MAT file should not contain any structures or row array's. It can have only column array's. Ofcourse, i know it is simple to change the column to row.

I dont think i can upload a file on to this blog, so till i can put the stuff on esnips this is the only way to share it.:-(


function mat2csv(fname,target)
% MAT2CSV convert a mat file to csv file
% MAT2CSV('matfilename.mat','csvfilename.csv')
% Output is generated using the data provided in the matfile ( one col per data element)
% Unused cells will be filled with zero's
% TODO: Currently the CSV file does not have column names, this will be
% added in next version
if(nargin<2)
    error 'Incorrect Number of inputs. Refer to usage by using "help mat2csv"'
end
y = open (fname);
largest_entry =0;
flds = fieldnames(y);
for idx=1:size(flds)
    eval ( strcat('if(size(y.',char(flds(idx)),',2)> largest_entry)largest_entry = size(y.',char(flds(idx)),',2); end'));
end
eval ('outmatrix = zeros(largest_entry,size(flds,1));');
for idx=1:size(flds)
    eval ( strcat('outmatrix(1:size(y.',   char(flds(idx)),  ',2),', int2str(idx) ,') = (y.', char(flds(idx)), ');')  );
end
fl ='';
for idx=1:size(flds)
    fl = strcat(fl,char(flds(idx)),',');
end
[rc,cc] = size(outmatrix);
fid=fopen(target,'wt');
fprintf(fid,'%s\n',fl);
for idx=1:rc
   for jdx=1:cc-1
        fprintf(fid,'%d,',outmatrix(idx,jdx));
    end
    fprintf(fid,'%d\n',outmatrix(idx,jdx+1));
end
fclose(fid);
end

Powered by ScribeFire.

Where does it run ?

This post comes in the wake up some discussions i had with few people working the embedded domain a few days back.

The question was, where exactly does our code in the micro controller run? The answer again unfortunately is not so straight forward. The reason is because different micro controllers behave in different ways. Let us therefore try to understand how the whole process works so that we can judge it better.

Frankly, the micro controllers at its core are just a bunch of registers on which a few mathematical operations can be done by another piece of hardware ( part of the core) called the ALU(Arithmatic Logic Unit). Most of the micro's thus have a Accumalator(Acc). This is like the mother register and most of the operations (mathematical or logical) will use the Acc register (There are instructions that do not involve the Acc also. like mov H,L does not involve the Acc). To ensure that some instrucution is executed, it must be first fetched, decoded and only there can be some action. To fetch an instruction, it should be readily available. Readily is a fuzzy word here because what is readily on 8Mhz system is really too slow on a 1GHz processor. The readiness depends on how fast we can read the said instrucution. The simplest micro controllers like 8051 keep the instructions in their flash memories. These are accessed by the core and then executed. Some industry folks call this as "Executing from the Flash".

Modern micro's have the concept of cache. This means they will pre-fetch and keep some of the instructions in a faster re-writeable memory. The core thus will use the cache to read the instructions instead of reading from the flash. Crude and simpler implementations of cache are in the form of instruction queue etc. These don't have the capabilities of the cache memory but never the less helps in making execution faster. So, now the instructions are stored in flash, but executed really out of cache memory.

Some micro controllers also provide a wonderful feature where in the instructions can be stored in the RAM. This is generally done while reprogramming. More about reprogramming will be there in future posts. Here the real program resides in the flash memory but one can copy the program to RAM and then set the core to fetch the instructions from the RAM instead of the flash.
Some folks call this "Execution from RAM".

The fact is that most modern micro's can read instructions from both Flash, Ram or in some cases even from communication buses (like CAN/FlexRay). The last part is tricky one and will be discussed in some other post ( because i have to get more information on that yet).

My take is this, all code gets executed in the core. All that can vary is where we are fetching it from.


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

Powered by ScribeFire.

Simulate Emulate and Debug....

Here i try to talk about a widely misunderstood topic. It is about Emulators, Simulators and Debuggers.

For starters, these three are different things and have different ways of operation and capabilities but have a common intent. Helping the embedded developer, develop his software in a more robust way with lesser number of bugs.

Lets start with the most common one, Simulator. A simulator is a software that runs on the host pc ( Your personal computer), and is able to mimic some/all of the behavior of micro controller. I use the term µC because that is what we will be dealing more in the future posts. However, this is equally applicable to the µC too. Some/all is in bold because simulators often cannot mimic all the functionalities that can occur in the real hardware. Some of the very good simulators i have seen are the AVR simulators. This should be available to you if you download AVR studio which i discussed in my earlier post here.

Next is a Debugger. A debugger is a device ( Typically an external peice of hardware connected to your PC via a serial link like USB) which talks to your µC and provides information to the host PC which is displayed in some kind of a debugging environment. Often the external hardware debugger is accompanied with a PC envirnonment to debug it and people confuse this environment to be the debugger. Unfortunately, that is incorrect. E.g of Debuggers 

• Nec Mini Cube with IEQB850 as the debugging environment
• ATMEL -ICE with AVR studio as the debugging environment.

Technically speaking, if you are a great PC prorgammer, then it should be possible for you to create your own debugging environment which talks to the hardware debugger and displays relavent information on your screen.
It should be obvious that to really use a debugger u needed a µC to which you can talk to. Without having a µC ( often called Target), there is not much you can do with a debugger.


Finally we have the Emulator. This is where everyone gets confused. An Emulator emulates the functionality of the µC. This means that the real µC is not present in the system. This is in contrast with the Debugger which requires an external µC to really talk to. Since, the Emulator emulates the functionality of the µC, there is no need for an extra µC. The question now arises why do we need an Emulator at all if we have a debugger? Why take pains to emulate the functionality of the micro when we already have it available?

Answer

• Often the real micro controller will be in developmental stages, while companies still want to use them. So Micro vendors like NEC come up with Emulators.
• Emulators can have more debugging capabilities compared to the real µC.
• Since, the Emulator is emulating the µC, it can be reconfigured via different means ( we will discuss this else where) to emulate more than one type of µC ( of course, not at the same time!!).

Eg: Nec IE-CUBE is a emulator for NEC V850 micro controllers

Costwise, typically simulators are cheap, Debuggers are costly and Emulators are very costly. Also, for debuggers to exist the µC should provide some kind of debug interface ( remember the debugger needs to talk to the micro!!). We will talk about debug interfaces in one of the future posts.

I hope this post helps people to lose some myths about the three components.

Wanna add your point or provide additional info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

ISR - Interrupt Service Routine

When i was in college i always wondered how my mouse clicks where recorded by winamp while it was actually busy playing music.
Only later during my second year in Engineering did i come to know about interrupts. This post is basically a quick and short intro to ISR's.

Interrupts are hardware or software generated events that get registered with the µC/ µP. So when i click my on my mouse, the hardware event generates a signal that goes and gets registered with the processor.
( Note: Actually this process is far more complicated since the interrupt passes through a Interrupt controller etc)

Once it is registered / recognized by the CPU, it then depends on the CPU is configuration whether the interrupt will be processed immediately or will it be kept pending. Processing or servicing of in interrupt is done by saving the current state of the µC and then executing the ISR. The fuzzy word here is current state. It is fuzzy because current state can mean different things in different situations. However, at minimum we know that we would need to save the address of the instrucution which we are currently executing so that after the ISR servicing we can return back to this point.

In real world situations, there can be many events that occur concurrently.

E.g. -> You can right click on the mouse while pressing a key on the keyboard.

How does the CPU handle it all?

The CPU handles this by using an on-chip  or off-chip peripheral unit called the Interrupt Controller. The Interrupt controller is capable of providing priorities to various interrupt sources.

E.g. -> In a Heater control system, the overtemperature event takes higher priority when compared to the User input event.

Apart from Handling the priorities of various interrupt sources, it also ensures that some of the events are masked. E.g you dont want an interrupt to bother you when you are doing some highly critical computation.
In many µC's the interrupt controller is on-chip. Usually, the software during the intialization of the system configures the interrupt controller so that it can prioritize the interrupts etc. In some controller dynamic priority is not available.

E.g. -> A watchdog Interrupt will always take higher priority than a timer interrupt.

So where is the ISR here?

The ISR is a set of instructions that the CPU executes when i detects and acknowledges a said interrupt. The Key word is acknowledges, because in some cases even though the interrupt is detected it will not be acknowledged.

E.g  ->while windows is booting up it might not want to acknowledge any mouse clicks.

At the end of the ISR (i.e the code in the ISR), the CPU returns back to the point where it has broken off to execute the ISR. Note that based on micro-controller architectures this will have differing behaviours when more than one interrupts are in pending state.

The concept of interrupts is very essential and is widely used in almost all embedded applications. Hence, a sound understanding of this concept is essential for anyone who wants to do some kind of embedded programming.



Wanna add your point or provide more info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Wow Effect

Finally I got my bike, the brand new shiny XCD 135. I still am new to it so my riding is extremely shaky. However, When i turned the key i got a cool effect in the console or more commonly called the cluster. The effect is called "The Wow Effect". This effect is nothing but sweeping of the needle in the meters from their rest position to their max and back in Jiffy.

These days instument clusters in two wheelers also have become extremely clever and show a whole bunch information. For a very long time the IC ( Instument cluster), was a fully mechanical device ( in two wheelers) with speed and RPM info coming to the IC via a rotating wire. The current clusters show efficiency, DTE ( Distance to Empty), Average speed, Trip info , RPM and speed information; To do all this they use complex electronics and a bevy of sensors which get them all the info.

Though the IC seems to be a very simple device, it holds fairly complex embedded software and hardware concepts.

I hope to see more interesting clusters in two wheelers in coming days...with much more information and bigger LCD displays

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