Monday, 29 December 2014

Upgraded Version of Digital Filter Plus Supports Q Format Fixed Point Numbers And Apple Mac OS X

The Digital Filter Plus filter design package has now been upgraded to support Q format fixed point number systems upto 64 bits long.
Digital Filter Plus is now also compiled for Apple Mac OS X.
Digital Filter Plus can be downloaded from here : http://www.numerix-dsp.com/dfplus/.
A free version for evaluation and non-commercial applications can be downloaded from here : http://www.numerix-dsp.com/free/.

The Next Round Of The University Of Oxford, UK DSP Courses Take Place In January 2016

As part of the University Of Oxford Summer Engineering Program for Industry, the DSP courses are returning in January. Here is a summary of the two courses.

Digital Signal Processing (theory and application) - Monday 25th to Wednesday 27th January 2016
http://www.conted.ox.ac.uk/courses/details.php?id=H600-24
This course provides a good understanding of DSP principles and their implementation and equips the delegate to put the ideas into practice and/or to tackle more advanced aspects of DSP. 'Hands-on' laboratory sessions are interspersed with the lectures to illustrate the taught material and allow you to pursue your own areas of interest in DSP. The hands-on sessions use specially written software running on PCs.

Subjects include :
Theoretical Foundations
Digital Filtering
Fourier Transforms And Frequency Domain Processing
DSP Hardware And Programming
ASIC Implementation
Typical DSP Applications
The course is presented by experts from industry for Engineers in industry.

Digital Signal Processing Implementation (algorithms to optimization) - Thursday 28th January 2016
A one-day supplement to the Digital Signal Processing course that takes the theory and translates it into practice.
http://www.conted.ox.ac.uk/courses/details.php?id=H600-25
The course will include a mixed lecture and demonstration format and has been written to be independent of target processor architecture.
The course will show how to take common DSP algorithms and map them onto common processor architectures. It will also give a guide line for how to choose a DSP device, in particular how to choose and use the correct data word length for any application.

Attendee Feedback from previous courses :
 It was informative, enjoyable and stimulating
 Excellent content, very lively thanks to the 2 excellent presenters - Anonymous
 A very good introduction to DSP theory
 Excellent lecturers! Really useful information and very understandable
 Great mix of theory and practice
 The lecturers gave a detailed and excellent explanation of the fundamental topics of DSP with real world engineering practice.
 This session closes the gap and clears up much confusion between classroom DSP theories and actual DSP implementation.
 Very good session, with in-depth discussion on the math and background.

The courses will be held at the University of Oxford, UK

Saturday, 25 October 2014

Building wxWidgets for Windows

I'm a big fan of wxWidgets (http://wxwidgets.org/) and have used it since its earliest days.

With the release of v3.x I have thought I would update many of the programs I have written over the years to be compatible with this version. The update process has been remarkably painless.

Here is how I build wxWidgets and applications to run under it.


Download wxWidgets-3.0.2.zip from : http://sourceforge.net/projects/wxwindows/files/3.0.2/
Extract to : C:\wxWidgets-3.0.2

Download Bakefile v0.2.9 from : https://github.com/vslavik/bakefile/releases

In : C:\wxWidgets-3.0.2\build\msw\
nmake -f makefile.vc BUILD=release clean
nmake -f makefile.vc RUNTIME_LIBS=static BUILD=release

I almost always use "RUNTIME_LIBS=static" because it saves having to include dlls with the application.

Set the WXWIN environment variable :
WXWIN=C:\wxWidgets-3.0.2

Open a command window in : C:\wxWidgets-3.0.2\samples\ - e.g. animate (C:\wxWidgets-3.0.2\samples\animate\)
nmake -f makefile.vc RUNTIME_LIBS=static BUILD=release
cd vc_mswud
anitest

Occasionally I will use the following for debugging but it is not very often because I still haven't found a better solution than printf (or fprintf for logging to a file) :
nmake -f makefile.vc RUNTIME_LIBS=static BUILD=debug


Tuesday, 9 September 2014

Controlling an AVB network from a Raspberry Pi

I’ve been playing with Audio Video Bridging (https://www.xmos.com/applications/avb) quite a bit lately and historically I’ve always used the AVDECC-Lib controller (https://github.com/audioscience/avdecc-lib) running on my laptop, either under Windows or Linux.

My intention is to create a completely standalone demo so I’ve since compiled the AVDECC-Lib controller for my Raspberry Pi.

The first thing to do is ensure that the GCC compiler is v4.7 :

sudo apt-get install g++-4.7
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6 
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7 
sudo update-alternatives --config gcc

Next we need to ensure that we have all of the required applications and modules :

sudo apt-get install cmake
sudo apt-get install git
sudo apt-get install libpcap-dev
sudo apt-get install libreadline-dev

Now we clone AVDECC-Lib from github :

git clone git://github.com/audioscience/avdecc-lib --recursive

Finally we build the library and application :

cd avdecc-lib
cmake .
make

Now we can run the controller and manage our AVB network :

sudo controller/app/cmdline/avdecccmdline

Note, it is necessary to use sudo because the application requires direct access to the Ethernet PHY.
The controller will now give you a list of network interfaces and you need to choose the appropriate one (2).

AVDECC Controller version: v0.4.9
1 (lo, address: <127.0.0.1>)
2 (eth0, address: <192.168.128.180>)
Enter the interface number (1-2): 2

That’s it, we are now at the controller command line :

Enter "help" for a list of valid commands.
$


Tuesday, 24 June 2014

New Co-Presenter on the University Of Oxford DSP Course

With the retirement of my previous co-presenter, Will, I have been searching for a suitably experienced FPGA / DSP designer to replace him. I am pleased to have Volker Mauer join and he will be bringing his many years of experience at Altera to the classes.

A limited number of spaces are still available on the July course : http://www.conted.ox.ac.uk/courses/details.php?id=H600-24


Tuesday, 3 June 2014

Gnuplot Installation Under Windows, Linux and MacOS - Solution

Judging by the number of people asking on the forums, this a very common FAQ.


Download and install Gnuplot from http://www.gnuplot.info/download.html.
Ensure that the Gnuplot binary folder is registered in the PATH environment variable so that you can call the Gnuplot executable from any folder.



You may find that Gnuplot reports that the wxt is an unknown terminal type; in which case, use the following command :

Uninstall your current version of Gnuplot and then install the +wxt variant.
port variants gnuplot to list available variants.
sudo port install gnuplot +wxwidgets


Note, after this I had to reboot MacOS to enable Gnuplot to recognize the new terminal types.


Under Linux you need to install both Gnuplot and Gnuplot-X11 :

sudo apt-get install gnuplot
sudo apt-get install gnuplot-x11


Sunday, 27 April 2014

The Noise Effects Of Aperture Jitter And Timing Variation

In any sampling system there is a requirement for the period between samples to remain constant within certain boundaries, the timing variation. Random noise on the timing is called the aperture jitter and the effect of it is to add noise on the digital samples; timing variation due to changes in the crystal oscillator frequency add a modulation artefact to the digital samples. These effects are shown in the following diagram.



The diagram shows that ts is the time of sampling the signal and it can be seen that if the time varies outside the limits shown by the arrows then the output will give the wrong digital value.

The range of analog converter performance requirements for different applications is very wide, ranging from 8 bits for instrumentation through 14 bits for telecommunications and control, 24 bits for pro-audio or seismic and sonar applications. So it is important that timing jitter and sinusiodal variations are managed to meet these requirements.

Any random component in the jitter can be removed by averaging however the sinusoidal component causes a modulation artefact that is often impossible to remove once present.

The timing variation artefact was was illustrated to me many years ago by a very experienced analog design engineer who hooked up the outputs of a dual frequency crystal oscillator to an oscilloscope set in X-Y mode. The display was setup in such a way that the Lissajou figure rotated slowly clockwise. He then proceeded to spray the oscillator with freezer spray and the scope display went crazy, finally slowing down to rotate in an anti-clockwise direction.

Why is this important ?

The main reason is that this sinusoidal component causes a modulation effect on the output of the ADC (or DAC) and this has serious implications in all DSP processing algorithms but especially those that perform any kind of modulation/demodulation or sample rate conversion.

Twice in my engineering career, once in a V.32 voiceband modem and secondly in a 3G mobile basestation, I have seen modems completely screwed up by using crystal oscillators that do not meet the required specification. The result was that the modems would work for a period of time and then fail with no apparent cause. In the case of the V.32 modem the failure only appeared to happen over night when the systems had been left running for many hours. Arriving at work in the morning was always a worrying time and caused a lot of stress for the team until the root-cause was found and fixed. We thought it might be temperature related (the modems at the bottom of the test rack ran for longer but all were within the temperature spec.), power surges, electrically noisy vacuum cleaners, the timing error detector algorithm, the Viterbi decoder etc in the end it turned out to be the crystal oscillator - some 100 ppm parts had been fitted instead of the specified 32 ppm version.

Accuracy And Precision

In my DSP classes I often cover the difference between precision and accuracy when measuring and processing input values from a transducer.
I recently came across an excellent little illustration of this on page 7 of the Keller-Druck Brochure : http://flipflashpages.uniflip.com/2/52802/96120/pub/#page7.

From a signal processing point of view the key points from this diagram are :
  1/ When the measurements are very precise (as shown in diagram A) then accuracy can be improved by removing the offset via subtraction of the average of the samples.
  2/ When measurements are more accurate but there is a larger deviation (as shown in diagram B) then the deviation can be reduced by oversampling and averaging the results.

Saturday, 29 March 2014

How Fast Are Our Digital Signal Processors ?

Since I started using DSPs in 1985 I been interested in how the clock speeds have been increasing. The very first DSPs appeared in the mid 1970s but I tracked the figures back to slightly pre-DSP days. This graph shows the Fixed-point DSP Mutiply Accumulate (MAC) Times (ns).

General Purpose Fixed-point DSP MAC Times (ns)
It is interesting to notice two particular elements of the graph :
    1/ The reduction in cycle times around the turn of the century as we moved to modern VLIW/SIMD architectures.
    2/ The squeeze on cycle times that has happened since the mid 2000s, in fact, if we were to put in 2014s figure it would be little different to the 0.8 of 2011.

Going forward it will be interesting to see if what technology, if anything, will come along that will allow future clock speed upgrades so that the DSP manufacturers don't just have to rely on parallel processing to provide increased performance.

Thursday, 30 January 2014

The Next Round Of The University Of Oxford, UK DSP Courses Take Place In July 2014

As part of the University Of Oxford Summer Engineering Program for Industry, the DSP courses are returning in July. Here is a summary of the two courses.

Digital Signal Processing (theory and application) - Tue 8th to Thu 10th July 2014
http://www.conted.ox.ac.uk/courses/details.php?id=H600-24
This course provides a good understanding of DSP principles and their implementation and equips the delegate to put the ideas into practice and/or to tackle more advanced aspects of DSP. 'Hands-on' laboratory sessions are interspersed with the lectures to illustrate the taught material and allow you to pursue your own areas of interest in DSP. The hands-on sessions use specially written software running on PCs.

Digital Signal Processing Implementation (algorithms to optimization) - Fri 11th July 2014
A one-day supplement to the Digital Signal Processing course that takes the theory and translates it into practice.
http://www.conted.ox.ac.uk/courses/details.php?id=H600-25
The course will include a mixed lecture and demonstration format and has been written to be independent of target processor architecture.
The course will show how to take common DSP algorithms and map them onto common processor architectures. It will also give a guide line for how to choose a DSP device, in particular how to choose and use the correct data word length for any application.

Attendee Feedback from previous courses :
 It was informative, enjoyable and stimulating
 Excellent content, very lively thanks to the 2 excellent presenters - Anonymous
 A very good introduction to DSP theory
 Excellent lecturers! Really useful information and very understandable
 Great mix of theory and practice
 The lecturers gave a detailed and excellent explanation of the fundamental topics of DSP with real world engineering practice.
 This session closes the gap and clears up much confusion between classroom DSP theories and actual DSP implementation.
 Very good session, with in-depth discussion on the math and background.

The courses will be held at the University of Oxford, UK

Wednesday, 15 January 2014

Interfacing C/C++ to Gnuplot

Over the years I have used many different applications for plotting DSP and scientific data (Matplotlib, MathGL, Grace etc) all have their benefits and disadvantages but I have never strayed far from the excellent Gnuplot.

Back in the early 1990s I wrote a library that worked with both the Borland and Microsoft C compilers (The Numerix Host Library) for displaying DSP data on old VGA screens. This library included it's own graphical plotting functions but over the years I have rewritten most of the library to interface to Gnuplot via an API that I call Gnuplot/C.

Gnuplot/C uses pipes to send data from C/C++ to Gnuplot's much more powerful graphical front-end.

Late last year, while updating some class notes for the Oxford University DSP Course, with some graphs generated using Gnuplot/C, I realized that it was about time I finally got around to documenting the API and making it available to others.

This was a perfect project for the Christmas/New Year holiday period and while the majority of the code was written then, the documentation took a little longer ;-)

Gnuplot/C is available from http://www.numerix-dsp.com/files.

One day I will port this to Python but maybe that is for another holiday ;-)

Finally, if you have found this solution useful then please do hit the Google (+1) button so that others may be able to find it as well.