Shy of Retiring

     It is common for DSP systems to be designed a bit poorlly in terms of the balance between ADC accuracy and clock accuracy. I think this is becaue many designers do not realise that the two are linked: error in the clock timing leads to errors in the sampled signal. The diagram shows an analogue signal which is held on the rising edge of a clock signal. If the clock edge occurs at a different time than expected, the signal will be held at the wrong value. In the diagram, the signal is rising and so the held value is higher than it should be. Errors introduced by timing jitter are as important as those caused by quantization, but are often forgotten. It is sadly common to see DSP systems where a lot of care has gone into the analog design and the selection of analog-to-digital converters with high precision and accuracy, but where the design is let down by a poor quality clock. A good design would balance the choice of clock accuracy against the ADC, and t...

     I am struck by how the term 'sample-and-hold' puts the two operations back-to-front. There are two steps to the conversion of an analog signal to digital form. The two are often confused, and the term "analog-to-digital conversion" is often (mistakenly) used to refer to both steps in the process. This confusion can hide important engineering choices. The idea of analog-to-digital conversion is to take a continually varying analog signal and convert that to a discrete set of samples taken (usually) at some regular time interval. The conversion is in fact a form of measurement, and for each sample will produce just one measured value. The problem here is, that the signal is continuously varying and so the (single) measurement will be some kind of average of the variation. Worse, the process of conversion to digital form can take some time and be done in stages - for example the method of "successive approximation" makes a first guess at the value, which...

Woking to London by bike.. From my home in Saint Johns (near Woking) I can cycle all the way into central London, most of the way off roads. It is a really nice ride, though the round trip takes me about 10 hours in all and is about 70 miles. Being off the roads is nice, but it does mean the surfaces are not so smooth so I find it quite long. Cycling past so many London bridges and landmarks as you arrive in London is so exciting though. :-) I think a good way to do this would be to cycle into London and then take the train home. I will try to arrange for a group of us to cycle this route in the Spring (of 2009) and on my last trip I photographed the landmarks, as well as pubs and places where people could join us or leave us if they wanted to cycle only part of the route. Obvious places to join are in Woking town centre, Weybridge and Kingston. Here I will describe the route, illustrating with the photos I took. We start from the pond outside Woking Golf Club ...

Timing error in sampling, and balanced ADC/clock choice It is common for DSP systems to be designed a bit poorlly in terms of the balance between ADC accuracy and clock accuracy. I think this is becaue many designers do not realise that the two are linked: error in the clock timing leads to errors in the sampled signal. The diagram shows an analogue signal which is held on the rising edge of a clock signal. If the clock edge occurs at a different time than expected, the signal will be held at the wrong value. In the diagram, the signal is rising and so the held value is higher than it should be. Errors introduced by timing jitter are as important as those caused by quantization, but are often forgotten. It is sadly common to see DSP systems where a lot of care has gone into the analog design and the selection of analog-to-digital converters with high precision and accuracy, but where the design is let down by a poor quality clock. A good design would balance the choice of cloc...

In my earlier post about embedded COM, I failed to mention one of the main motivations: dynamic linking. In embedded systems resources are constrained. So overheads are kept low. Component models that use static linked libraries tend to be simpler, and so have been preferred in the embedded world (not that component models have yet proven all that popular in embedded systems anyway). Also, static linked models let the compiler check for depenedencies - for instance detecting if a required component is in fact not present. So a dynamic linked model (like COM) suffers from greater overheads, and also from more likely run-time errors due to requested component not in fact being there. The first (overhead) can be limited by adopting only a subset of COM - and is a prime reason for not following Microsoft into .NET which has a much bigger run-time system overhead due to the greater sophistication of the .NET run-time library. The second (run-time errors) requires programmers to p...