Showing posts from April, 2016

Training the trainers?

I have been developing a new training class that aims to teach engineers how to develop and present technical training that is effective. I have read lots of books on presentations and on training, and have come to believe that much of what they say is at best irrelevant. They concentrate a lot of what I think are side-issues - like 'body language' or font sizes for slides. They also often seem to me to be patronising - the standard advice to have 'no more than three points per slide' is insulting to engineers who are quite capable of reading and following a very complex schematic diagram that conveys a huge amount of information in a condensed form. I read one book that advised me to "make sure you know where the presentation is to be held". Well, I suppose that is sound advice but if someone can't figure out they need to know where to go then I don't want to waste my time with them - I am aiming for people who are not totally clueless. This ma

Motivations for an embedded COM

Preparing some training that includes dealing with an embedded COM implementation, I have been thinking about why COM might be adopted in preference to some other component model? In the domains I am considering, a prime motivation for component architectures is to standardize nd so to encourage the growth of a market in third-party components. Microsoft’s Component Object Model (COM) is attractive because it is a simple model that is widely used and well documented. COM is actually quite a small subsystem - a usable subset can be implemented for MIPS in less than 10 k. A full implementation provides functionality that may be unnecessary, and imposes overheads that are undesirable in real-time embedded systems, but a subset that avoids the more esoteric parts can be very useful. Other software component models have been defined that target real-time embedded systems. For example Philips’s Koala component model for consumer electronics, the commercial product ControllShell, and ACC

Geometric signal interpretation of complex exponential oscillators

    Following from my last post on geometric interpretation of complex numbers, I looked for a clear explanation of complex exponentials. The model of complex exponentials: a = a ejA = a cos(A) + j * a sin(A) lets us use complex arithmetic to do things with vectors. To see how this can be used to model real signals, think about a rotating wheel with a knob on. I found a nice animation of this by Jim Lesurf of the University of Saint Andrews which has a nice beach (though very cold) and a famous golf course nearby. His animation is at: and I borrowed his pictures (with permission) to use in the slide I generated (an extract from which is shown above). If we look at the wheel from the front, we can see that the motion of the knob is circular. But if we look from the side, it looks as though the knob just goes up and down - and if we plotted its up- and down-ness against time this would be a sine wave. Think

Geometric signal interpretation of complex numbers

    In revising the slides and notes for our class Introuction to DSP, I decided to add some explanation of complex numbers and how they relate to the real world. This is important because we actually develop DSP math using complex numbers, although most often we explain it (informally) without recognizing this. Using complex numbers is useful because the math works well, but is often difficult for people to understand in practical terms - that is, what does the complex number represent? In fact, though, many signals are easier to deal with if we think of them as being ‘2-dimensional’ vectors. A vector has both length and direction (or, in an x/y coordinate system, two components - x and y). For example think of a sine function: at first sight this seems to be a classic case of a 1- dimensional signal - it has just one varying value (the sine). But a sine value is in fact derived from trigonometry, based on the ratio of the lengths of the sides of a right-angled triangle - the


I was talking to my wife Sarah the other day about DSP - enthusing in fact. I have been involved with DSP through my whole career (which makes it now 35 years), and I love the subject. DSP is really exciting. Not just because of its applications but for the thrill of new insights into the subject itself. And yet DSP is regarded as a ‘hard’ subject, and one that most people avoid - their dread for the topic only increased by typical exposure to an undergraduate DSP course. So I was enthusing about how  lucky I am to work in such a fun and exciting field but also worrying, as I do, about the flawed ways in which it is taught and the puzzle of such a cool subject being thought so hard and dull. What I want, I was saying, is to teach people DSP so that they enjoy and love it as much as I do - so that they want to pursue careers in this, my own field, and so that they can benefit from insights that I have gained over years and do it really well. I was also explaining (I think ‘going on’