I recently tried to install Gnuplot/C on a Mac.

I tried "sudo port install gnuplot +wxwidgets" but ran into the DNS problem : https://trac.macports.org/wiki/MisbehavingServers.

I doubt my ISP is going to change their ways at my request so I tried Brew instead :

$ Brew install gnuplot --with-wxmac

Perfect, lets test gnuplot :

$ gnuplot

gnuplot> plot sin(x)

Excellent, a nice little sinusoid.

Now let's test Gnuplot/C :

$ cd gnuplot_c/examples/

$ ./br.sh LinesAndPoints

sh: /dev/nul: Permission denied

sh: /dev/nul: Permission denied

Oops. Another quick search suggested :

$ sudo mknod /dev/nul c 1 3

$ sudo chmod 666 /dev/nul

Now let's test Gnuplot/C again :

$ ./br.sh LinesAndPoints

Excellent. All running nicely :-)

# The Numerix DSP Blog

All things DSP and some more ...

## Thursday, 19 January 2017

## Sunday, 8 January 2017

### Some Thoughts On Benchmarking Applications On A Pentium PC (Windows/Mac/Linux)

The ability to benchmark DSP algorithms to check that they execute in real time is a key part of the DSP development process. I've written several blog posts on the subject including :

http://blog.numerix-dsp.com/2013/01/how-to-benchmark-some-c-code-or.html

http://blog.numerix-dsp.com/2015/01/timing-code-running-on-xmos-xcore.html

While benchmarking code to run on a traditional DSP or embedded microcontroller is a relatively simple task, due to the deterministic nature of DSP architectures, doing the same on a Pentium PC is quite tricky. I've recently tried two of the most common techniques for benchmarking DSP algorithms on a Pentium PC. The two techniques are :

Reading the Pentium Time Stamp Counter Register : http://stackoverflow.com/questions/9887839/clock-cycle-count-wth-gcc

Instruction counting using GDB : http://stackoverflow.com/questions/21628002/counting-machine-instructions-using-gdb

The Time Stamp Counter option has a lot of disadvantages when used in a multi-tasking OS due to the whole task switching happening in parallel with the application.

The inital overhead calculation may take longer, due to a task switch, so the final benchmark may take less than 0 cycles when subtracting the overhead of calling the timer functions.

The GDB solution counts instructions but does not allow for pipelining, caching, and run-time parallel instruction execution.

So far the only option I have come up with is to use a statistical analysis of the results to get an approximation to how efficient an algorithm is.

Here are some results from some different filter functions that I have benchmarked (more details in an upcoming post about the different filtering functions).

The TSC technique shows that runtime parallelization of code gives better than 1 instruction per cycle execution but each mode was executed a twenty times and the average result was taken so take note of the problems listed above.

MODE GDB TSC

1 2514 975

2 1171 754

3 1188 547

In summary, GDB instruction counting gives a good approximation to how efficient an algorithm is but the Time Stamp Counter solution gives a better estimate to the actual number of CPU clock cycles are required.

http://blog.numerix-dsp.com/2013/01/how-to-benchmark-some-c-code-or.html

http://blog.numerix-dsp.com/2015/01/timing-code-running-on-xmos-xcore.html

While benchmarking code to run on a traditional DSP or embedded microcontroller is a relatively simple task, due to the deterministic nature of DSP architectures, doing the same on a Pentium PC is quite tricky. I've recently tried two of the most common techniques for benchmarking DSP algorithms on a Pentium PC. The two techniques are :

Reading the Pentium Time Stamp Counter Register : http://stackoverflow.com/questions/9887839/clock-cycle-count-wth-gcc

Instruction counting using GDB : http://stackoverflow.com/questions/21628002/counting-machine-instructions-using-gdb

The Time Stamp Counter option has a lot of disadvantages when used in a multi-tasking OS due to the whole task switching happening in parallel with the application.

The inital overhead calculation may take longer, due to a task switch, so the final benchmark may take less than 0 cycles when subtracting the overhead of calling the timer functions.

The GDB solution counts instructions but does not allow for pipelining, caching, and run-time parallel instruction execution.

So far the only option I have come up with is to use a statistical analysis of the results to get an approximation to how efficient an algorithm is.

Here are some results from some different filter functions that I have benchmarked (more details in an upcoming post about the different filtering functions).

The TSC technique shows that runtime parallelization of code gives better than 1 instruction per cycle execution but each mode was executed a twenty times and the average result was taken so take note of the problems listed above.

MODE GDB TSC

1 2514 975

2 1171 754

3 1188 547

In summary, GDB instruction counting gives a good approximation to how efficient an algorithm is but the Time Stamp Counter solution gives a better estimate to the actual number of CPU clock cycles are required.

## Tuesday, 3 January 2017

### Gnuplot/C Update II

A new version of Gnuplot/C has been uploaded to SourceForge that includes polar plotting capabiliites : https://sourceforge.net/projects/gnuplotc/.

This adds logarithmic x-axis support to the existing plot types.

Here is an image showing the capabilities :

The DTMF tones were generated using the SigLib DSP library.

This adds logarithmic x-axis support to the existing plot types.

Here is an image showing the capabilities :

The DTMF tones were generated using the SigLib DSP library.

## Saturday, 24 December 2016

### Gnuplot/C Update

A new version of Gnuplot/C has been uploaded to SourceForge that includes polar plotting capabiliites : https://sourceforge.net/projects/gnuplotc/.

This adds to the existing plot types :

Line Plot

XY Plot

Pole-Zero Plot

Spectrogram Plot

Image Plot

This adds to the existing plot types :

Line Plot

XY Plot

Pole-Zero Plot

Spectrogram Plot

Image Plot

## Thursday, 22 December 2016

### Polar plot in Gnuplot

I was recently playing with microphone array polar diversity responses and did a search for suitable Gnuplot solutions. There are a number that turned up but none of them really matched my requirement so here it is :

set polar

set angle degree

set size ratio 1

set tmargin 3

set bmargin 3

set title "Microphone Polar Diversity Response : Mic Spacing 0.1 (meters)"

set key out vert nobox

set style line 1 lc rgb 'gray80' lt -1

set grid polar ls 1

unset border

unset xtics

unset ytics

f_maxGain=0. # Maximum gain - MUST BE FLOATING POINT

minGain=-80 # Minimum gain - MUST BE INTEGER

tickstep = 10 # Ticks every 10 dB

numticks = 8 # numticks = r / tickstep :: Don't use divide because numticks is used in for loop and doesn't work

f_numticks = 8. # Floating point numticks

set rrange [minGain:0]

set rtics tickstep format '' scale 0

set label '0°' center at first 0, first -minGain*1.05

set label '90°' right at first -minGain*1.05, 0

set label '180°' center at first 0, first minGain*1.05

set label '270°' left at first minGain*1.05, 0

set for [i=.1:numticks] label at first minGain*0.001, first minGain*((i/f_numticks) + 0.007) sprintf("%d dB", minGain+(i*10))

unset raxis

plot "250.dat" u (-$1+90.):($2-f_maxGain) t "250 Hz" w lines lc rgb "magenta", \

"500.dat" u (-$1+90.):($2-f_maxGain) t "500 Hz" w lines lc rgb "red", \

"1000.dat" u (-$1+90.):($2-f_maxGain) t "1000 Hz" w lines lc rgb "blue", \

"2000.dat" u (-$1+90.):($2-f_maxGain) t "2000 Hz" w lines lc rgb "cyan", \

"4000.dat" u (-$1+90.):($2-f_maxGain) t "4000 Hz" w lines lc rgb "orange"

print "Hit <CR> to continue ..."

pause -1

The data was generated in a C program. The files look like this (i.e. two columns angle and gain) :

# Antenna Beam Pattern

# Angle Gain

-9.00e+01 -1.17e+00

-8.90e+01 -1.17e+00

-8.80e+01 -1.17e+00

Here is the plot for 100 mm mic spacing :

The gnuplot script allows the min and max gain values to be changed.

set polar

set angle degree

set size ratio 1

set tmargin 3

set bmargin 3

set title "Microphone Polar Diversity Response : Mic Spacing 0.1 (meters)"

set key out vert nobox

set style line 1 lc rgb 'gray80' lt -1

set grid polar ls 1

unset border

unset xtics

unset ytics

f_maxGain=0. # Maximum gain - MUST BE FLOATING POINT

minGain=-80 # Minimum gain - MUST BE INTEGER

tickstep = 10 # Ticks every 10 dB

numticks = 8 # numticks = r / tickstep :: Don't use divide because numticks is used in for loop and doesn't work

f_numticks = 8. # Floating point numticks

set rrange [minGain:0]

set rtics tickstep format '' scale 0

set label '0°' center at first 0, first -minGain*1.05

set label '90°' right at first -minGain*1.05, 0

set label '180°' center at first 0, first minGain*1.05

set label '270°' left at first minGain*1.05, 0

set for [i=.1:numticks] label at first minGain*0.001, first minGain*((i/f_numticks) + 0.007) sprintf("%d dB", minGain+(i*10))

unset raxis

plot "250.dat" u (-$1+90.):($2-f_maxGain) t "250 Hz" w lines lc rgb "magenta", \

"500.dat" u (-$1+90.):($2-f_maxGain) t "500 Hz" w lines lc rgb "red", \

"1000.dat" u (-$1+90.):($2-f_maxGain) t "1000 Hz" w lines lc rgb "blue", \

"2000.dat" u (-$1+90.):($2-f_maxGain) t "2000 Hz" w lines lc rgb "cyan", \

"4000.dat" u (-$1+90.):($2-f_maxGain) t "4000 Hz" w lines lc rgb "orange"

print "Hit <CR> to continue ..."

pause -1

The data was generated in a C program. The files look like this (i.e. two columns angle and gain) :

# Antenna Beam Pattern

# Angle Gain

-9.00e+01 -1.17e+00

-8.90e+01 -1.17e+00

-8.80e+01 -1.17e+00

.

.

Here is the plot for 100 mm mic spacing :

The gnuplot script allows the min and max gain values to be changed.

## Wednesday, 16 November 2016

### The Next Round Of The University Of Oxford, UK Digital Signal Processing Courses Take Place In July 2017

As part of the University Of Oxford Summer Engineering Program for Industry, the Digital Signal Processing courses are returning in July 2017.

The courses are presented by experts from industry for Engineers in industry.

Here is a summary of the two courses.

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

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.

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

The courses are presented by experts from industry for Engineers in industry.

Here is a summary of the two courses.

## Digital Signal Processing (Theory and Application) - Tuesday 4th to Thursday 6th July 2017

http://www.conted.ox.ac.uk/courses/details.php?id=H600-24This 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

## Digital Signal Processing Implementation (algorithms to optimization) - Friday 7th July 2017

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.

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

## Sunday, 9 October 2016

### FIR Filter Design Notes

When designing an FIR filter it is handy to know how many coefficients are required for your desired implementation.

The Kaiser approximation is the algorithm that tells you how many coefficients your filter will need but not what those coefficients are. It is accurate when using an approximation design algorithm such as the Parks-McClellan (Remez exchange) algorithm.

For designing filters with the windowing functions there are no direct equivalents to Kaiser's approximation, it is more that you have to look at the characteristics of your signal requirements and compare them to the capabilities of the windowing functions. Note : filters designed using windowing functions will typically be longer than those designed using Parks-McClellan.

SigLib includes a range of windows based filter design functions. At the present time it does not include a version of the Parks-McClellan algorithm because there are so many already available. I had a customer recently use this : http://www.iowahills.com/Example%20Code/NewParksMcClellan.txt.

I haven't used this myself but I have heard good reports.

The Kaiser approximation is the algorithm that tells you how many coefficients your filter will need but not what those coefficients are. It is accurate when using an approximation design algorithm such as the Parks-McClellan (Remez exchange) algorithm.

For designing filters with the windowing functions there are no direct equivalents to Kaiser's approximation, it is more that you have to look at the characteristics of your signal requirements and compare them to the capabilities of the windowing functions. Note : filters designed using windowing functions will typically be longer than those designed using Parks-McClellan.

SigLib includes a range of windows based filter design functions. At the present time it does not include a version of the Parks-McClellan algorithm because there are so many already available. I had a customer recently use this : http://www.iowahills.com/Example%20Code/NewParksMcClellan.txt.

I haven't used this myself but I have heard good reports.

Subscribe to:
Posts (Atom)