Shy of Retiring

Working on a new training class in digital camera design, I found it hard to describe the processes and things involved in capturing and processing a 'digital image' without using words that themselves are based on an intuitive understanding of what an image 'is'. Take this statement: "a digital camera takes a picture". It looks straightforward until you look closer and see that it is in fact quite subtle. This is not just because searching for clear definitions can take us in a circle (for instance Google defines a 'picture' as a 'visual representation', a 'representation' as an 'image' and an 'image' as a 'picture'). It is also that the language to reason about images is itself based on imagery. If I want to explain some aspect of an image processing problem then I might choose something to 'illustrate' the problem. Or I might ask you to try to 'see' the problem from a particular 'p...

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...

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...

    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: http://www.st-andrews.ac.uk/~www_pa/Scots_Guide/info/signals/complex/cmplx.html 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 si...

    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 ...

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 ...

I am working on several papers, and a new training class, explaining software component architectures especially in relation to streaming media and DSP. This is interesting and I am gaining some valuable new insights into these topics. Software component architectures let you build systems by connecting pre-existing components. A software component is a piece of code that is re-usable in many applications: extending the idea of re-usable software functions to cover larger blocks of code but also letting the components be deployed and version-controlled independently of the applications that use them. The aim is re-use instead of re-invention: to make software components that, like hardware components, can be used again and again, interchanged and relied on. This is a difference between components and objects: objects try to correspond to a reasonably clear mental model of the actual objects that make up the system, and so encourage us to design objects that do make sense in this way. ...