sharadsinha

Posts Tagged ‘Errors’

Component Problems with Electronic Systems

In Education, Embedded Systems, Engineering Principles on December 30, 2014 at 9:37 PM

It is not surprising to find component problems with electronic systems. I was working with a Zedboard recently and it would just not boot from the supplied SD card. The serial driver was properly installed but the LED would not light up. The host PC’s operating system did not complain about any driver issues. Some members on the Zedboard forum complained about the micro-USB socket problem on the board. In any case, when working with a development or an evaluation board, it can become difficult to diagnose such issues. I tried different SD cards as well but to no use.  My laptop can recognize the SD card but Windows is unable to format it!

This experience makes me feel that it is relatively easier to simulate a design and test it for functional correctness. It is more frustrating when components on a board stop working and you do not know which one. For my case, the SD card could be corrupt, the SD card reader could be corrupt; according to forums, there may be issues with the serial port driver etc. It is not that it is difficult to diagnose the issue. It is just that you have try to isolate the problem by looking at different possible issues one by one. It wastes a lot of time especially when you expect a dev/eval board to be up and running quickly.

One board can take away so much time. Imagine if you have to do this for 20 such boards which is usually the case when such boards are procured for student laboratory exercises! Can’t there be a better way to know the status of components? Perhaps it is time to investigate this!

Advertisements

Chasing Numbers

In Education, Engineering Principles, Mathematics, Research and Development on September 28, 2014 at 8:35 PM

In his book The Tyranny of Numbers: Mismeasurement and MisruleNicholas Eberstadt says, “Although he may not always recognize his bondage, modern man lives under a tyranny of numbers.” Other writers have also commented on how and why numbers alone cannot make us happy and how numbers can be both enlightening as well as confusing if not presented with the right kind of background information. This is very true with research literature, specially those pertaining to engineering and science disciplines where measurement plays a very important role in conveying one’s ideas to convince someone of their importance. I see this everyday when I read research papers. Sometimes I even see numbers and graphs which seemingly do not have any major relation to the central idea of the paper. Such numbers, graphs and tables are byproducts of primary measurement but are probably included with the hope that more numbers, graphs etc. make the papers not only look good but also appear convincing. Given the very short amount of time that most reviewers spend on a paper, it is only sometimes that one finds reviewers commenting on the unnecessary usage of such secondary artifacts. However, a cursory glance does make the paper look good and does give the impression that the authors have spent time analyzing their results (though this may not be the case).

When I see such papers I am reminded of Eberstadt’s statement. It makes me wonder if engineering and science people read papers and books from the field of social science or history or say English literature. Research is conducted even in these disciplines and data is also collected and analysed where needed. However, the force of the argument generally comes from rigorous analysis and reasoning. It is not always driven by the logic that since this paper achieves number X compared to number Y (where say Y is less than X), the proposed methodology is better than the one related to number Y. I have read Diffusion of Innovation by Everett M. Rogers and I have found it to be immensely enlightening. It not only uses numbers but also the force of reasoning. This is so strong that you begin to see what the author is trying to say. I wonder how, say a computer engineering scientist would review a sociology research paper.

Have you ever tried reviewing a paper or a book outside of your major discipline and trying to understand its logical progression?

Numerical Stability in Calculations

In Design Methodologies, Embedded Systems, Engineering Principles, Mathematics on January 24, 2013 at 11:44 PM

I did not have any course on algorithms in my undergraduate education. I studied about them (their properties, design etc.) during my research work. I now realize why their study is important for anyone who wants to be really good at designing algorithms or implementing them. After all, algorithms solve problems. I recently came across the subject of numerical stability of algorithms, numerical algorithms to be precise. While algorithms help solve problems, they need to be implemented on a digital machine (a computer for example) which has limited precision. Whatever number system we use, they cannot cover all the numbers present in exact  mathematics. This leads to approximations as well as upper and lower bounds on the numbers that can be represented. Also, approximations can be the source of errors and deviations from the exact numerical answer. For instance, on a machine with only 3 digit precision, numbers like 22, 2.22, 0.110, 100, 177 can be represented. Now if you try to add 2 and 1000 instances of 0.11 , your sum would be 112 on this machine and this matches with the exact answer. Similarly, if you try to add 9 and 9 instances of 0.11, the answer on this machine would be 9.99, which matches with the exact answer. However, if you try to add 10 and 9 instances of 0.11 in that order i.e 10+0.11+0.11…., the machine would return 10 as answer because the moment you try to add 0.11 to 10, you are going to exceed the precision of the machine. Now imagine doing the same calculation in the reverse order i.e adding all the nine 0.11’s first and then 10 i.e. 0.11+0.11+….+10, the machine would return an answer of 0.99 which is far off from the actual answer 10.99 and far worse than the previous approximation of 10 (for the other order of addition). This means that the way you arrange your numbers( in memory, for instance an array) to be added also may influence the sum!! I wish that embedded systems engineers read more on this subject so that the numerical errors that we see cropping up in such systems get reduced. A nice introduction is at wikipedia.

Velocity, Displacement & Acceleration: Science vs. Engineering

In Design Methodologies, Education, Engineering Principles on December 24, 2012 at 7:04 PM

One often encounters the question: What is the difference between science and engineering? An oft quoted answer is that engineering involves, roughly speaking, an application of science or scientific results borne out of investigation into the nature of matter and its interaction with its surroundings. Science is about acquiring more knowledge and understanding about existing phenomena whereas engineering involves solving problems by applying that knowledge. Therefore, many also hold the view that it is applied science. Well, I won’t get into the debate of engineering vs. science or put before you an essay on this topic in this post. I would just like to highlight an example of where engineering takes over from science. Every student studies the concepts of velocity, acceleration and displacement in elementary Physics classes. These concepts are very simple: velocity is the derivative of displacement with respect to time while acceleration is the derivative of velocity with respect to time. Therefore to get displacement from velocity , one needs to integrate the former with respect to time over a given time period. Similarly, velocity at a certain point in time is the result of integration of acceleration over a given time interval. Now, if one is asked to apply these principles to calculate velocity and displacement using the acceleration data obtained from a transducer mounted on an engine, how would one do it? In this case, the engine vibrates and there is no physical noticeable movement of engine body from one place to another in the traditional sense (like a ball traveling from place A to place B in a field). This is where engineering comes in. An engine is a complex system and its vibrations need not be linear or constant in time. There can be vibrations with low frequencies as well as high frequencies and there can be periods of no vibration at all. In these cases, calculation of displacement or velocity is not straight forward and requires greater insight into the mechanism of vibration as well as the nature of acceleration signal. I would recommend reading up 1, 2 and 3 to get an idea of how interesting and insightful it can become! These are links to articles by Prosig  which works in the area of noise and vibration analysis. Understanding these mechanisms is important for any embedded designer who writes code to measure such parameters using microcontrollers etc.

Error Documentation: Why not?

In Design Methodologies, Embedded Systems on August 27, 2012 at 12:48 PM

I am sure that many of you who have used any software tool that throws up errors have spent time (at one point or another) figuring out what those errors mean. Every software tool that is used in any electronics or software design project throws up errors. Be it is GCC, EDA tools etc. One might have used the support channel of the vendor, user forums, websites like stackoverflow etc. to understand the meaning of those errors. A number of times, these errors do not make any immediate sense to the user. There are also many errors which can be because of multiple reasons. Once one gets a list of these reasons, one has to choose the one that is most likely to be applicable to the case at hand. All this reduces productivity. The time spent searching, gathering and analyzing information could have been better utilized focusing on design. Would it not be better if tool vendors also released documentation on the different kinds of errors that their tools might throw up and the associated reasons? I believe that this “ready-reference” would be very beneficial. After all during the development of those tools, the vendors are indeed aware of why a particular error has been thrown up. Why not just compile all that information in one place and help the user? Also, the errors are not always due to problems in the design source files. Sometimes they are there because the tool expects the user to structure the project, tool inputs etc. in a certain way. Given the complexity of modern EDA and other development tools and the time spent in learning them for effective use, it would only be welcomed if vendors offered this extra level of documentation.