Monday, 1 July 2013

Digital Signal Processing - Bibliography

Here is a list of references that I have used over the years.

My goto reference for DSP is Oppenheim and Schafer's Discrete Time Signal Processing but for learning DSP I recommend Steven Smith's The Scientist and Engineer's Guide to Digital Signal Processing. Please see this blog entry :


As a point of historical note Park's Principles of Sigma-Delta Modulation for Analog-to-Digital Converters is a really useful reference for any narrow band signal processing applications and I have used it as a reference for wireless and ultrasound applications. If you can find a copy on the web it is well worth a read.

Analog Devices, DSP Applications Using The ADSP-2100 Family, Prentice Hall, USA.
Antoniou, A., (1993), Digital Filters : Analysis, Design and Applications, McGraw-Hill, USA.
Bellanger, M., (1984), Digital Processing Of Signals, Theory And Practice, John Wiley & Sons, UK
Burrus, C. S. and Parks, T. W., (1985), DFT/FFT and Convolution Algorithms, Wiley Interscience, NY, USA.
Cooley, J.W. and Tukey, J.W., (1965), An Algorithm for the Machine Calculation of Complex Fourier Series, Mathematics of Computation, The American Mathematical Society, USA.
Defatta, D. J., Lucas, J. G. and Hodgkiss, W. S., (1988), Digital Signal Processing - A system Design Approach, John Wiley & Sons Inc., USA.
Higgins, R. J., (1990), Digital Signal Processing in VLSI, Prentice-Hall, Englewood Cliffs, N.J., USA.
Harris, F.J., (1978), On The Use of Windows For Harmonic Analysis With the Discrete Fourier Transform, Proc. Inst. Electrical and Electronic Engineers, January.
Kay, Modern Spectral Estimation, Prentice-Hall Inc., USA
Knuth, D. E., (1981), Seminumerical Algorithms, vol 2 of The Art of Computer Programming, Addison-Wesley, USA.
Park S., Principles of Sigma-Delta Modulation for Analog-to-Digital Converters (APR8.PDF), Motorola Inc., USA
Marple, Digital Spectral Analysis with Applications, Prentice-Hall Inc., USA
Nussbaumer H., Fast Fourier Transform and Convolution Algorithms
Qian, S and Chen, D., (1996), Joint Time-Frequency Analysis, Prentice-Hall Inc., USA.
Oppenheim, A. V. and Schafer, R. W., (1989), Discrete Time Signal Processing, Prentice-Hall Inc., USA.
Orfanidis, Sophocles J., Introduction to Signal Processing, Prentice Hall, Inc. : http://eceweb1.rutgers.edu/~orfanidi/intro2sp/
Proakis, J. G., and Manolakis, D. G., (1992), Digital Signal Processing - Principles, Algorithms and Applications (2ed), Prentice-Hall, USA.
Proakis, J. G., Rader C. M., Ling, F. and Nikias, C. L., (1992), Advanced Digital Signal Processing, Macmillan Inc.
Smith, Steven W., The Scientist and Engineer's Guide to Digital Signal Processing : http://www.dspguide.com
Sorensen, H. V., Jones, D. L., Heideman, M. T. & Burrus, C. S., (1987), and Sig. Proc., Vol ASSP-35, No Real-valued Fast Fourier Transform Algorithms, IEEE Tran. Acoustics, Speech 6 pgs 849-863. (1981)
Stimson, G. W., (1998), Introduction To Airborne Radar (2ed), Scitech Publishing, USA.


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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Copyright © 2013 Delta Numerix

Sunday, 30 June 2013

DSP Tech Brief : Some Notes On Implementing DSP Algorithms - C or Assembly, Fixed or Floating Point

There are many practical issues to consider when implementing DSP applications, including whether to choose fixed or floating-point devices, whether to program in a high level or assembler code. Here are some notes on the issues that may help guide a decision

One of the most popular techniques for developing DSP systems is to simulate the system in C on a general purpose micro-processor and then port the C code onto a DSP device, for many applications the C may give perfectly acceptable performance, in others however some of the routines must be coded in hand optimized assembler. Many of these functions can be easily optimized by compiling to assembler and then hand optimizing.

The choice between fixed and floating point devices is quite fundamental to an application. Fixed point devices generally have a higher clock speed due to their smaller size because they do not have the extra complexity of the floating point hardware. They are also produced in larger quantities which means that they benefit from the cost savings of mass production and they can therefore sell for a lower cost.

Floating-point devices give a higher dynamic range, which will allow more complex applications to be implemented for example a large 2D FFT can require a very large dynamic range, despite the limited resolution of the input, in this case it is almost certain that fixed point devices would not be suitable. One of the problems with fixed point devices is that the programmer must always be aware of the fact that the device can overflow its numerical bounds and if this is likely then the numbers should be scaled appropriately before continuing the process. The scaling can be quite time consuming and as a rule of thumb an FFT of more than about 1024 or 2048 points is quicker on a floating-point device, despite the faster clock speed of fixed point DSPs. Although floating-point devices give a larger dynamic range a floating-point device with a given mantissa length will give no greater precision than a fixed-point device with the same size word length.

When coding real-time routines in C there are some rules that can be followed to make the code as efficient as possible. First, all function parameters and local variables are placed on the stack and so they are accessed indirectly. This can often be over come by using compilers that use registers for variables but it is often the case that the code can be optimized by careful choice of register variables and by using global variables which are placed on the heap. When implementing interrupt service routines all registers that are used must be pushed onto the stack, to prevent side effects. In some cases using higher levels of optimization and hence extra registers for interrupt service routines may actually slow them down, due to the overhead of the extra stack manipulation that is required at both the start and end of the ISR.

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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Copyright © 2013 Delta Numerix

Saturday, 29 June 2013

Another Good Way To Learn DSP – Online Courses

A while back I wrote an entry called : What Is The Best Way To Learn Digital Signal Processing. This listed a couple of signal processing related books that are available for download, for free. Another good way to learn DSP is to view some of the DSP Courses available on YouTube. In particular, these two are excellent. Don’t be put off by the fact that Alan’s is from 1975, fundamental theories don’t follow Moore’s Law ;-)


Of course, as good as these courses are, they don’t replace an instructor led course, like the ones from Oxford University ;-)

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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Copyright © 2013 Delta Numerix

Friday, 8 March 2013

RaspBMC Hints And Tips

Having setup RaspBMC on my Pi I found that when playing music, that the display mode would go into fullscreen mode and I couldn't change the display mode using the standard TV remote control. With a little bit of playing I noticed that the Red, Green, Yellow and Blue buttons performed the following operations :
      Red : PVR

      Green : Videos
      Yellow : Music
      Blue : Pictures
I haven't got a PVR connected to the Pi so I figured I could reuse the Red button to swap in and out of fullscreen mode.

A quick web search showed that the key mappings are stored in the file :

/opt/xbmc-bcm/xbmc-bin/share/xbmc/system/keymaps/remote.xml
Loading this into nano and searching for "red" (without quotation marks) showed the following lines of code :

      <red>XBMC.ActivateWindow(MyPVR)</red>
      <green>XBMC.ActivateWindow(MyVideos)</green>
      <yellow>XBMC.ActivateWindow(MyMusic)</yellow>
      <blue>XBMC.ActivateWindow(MyPictures)</blue>
I then changed the <red> line to :
      <red>FullScreen</red>


I also wanted to change the fastforward and rewind buttons to skip forward and back in the tracklist so I made the following changes :
      <forward>FastForward</forward>
      <reverse>Rewind</reverse>
To :
      <forward>SkipNext</forward>
      <reverse>SkipPrevious</reverse>


I then saved the file and after a quick reboot everything worked as required.

I will update this post with new hints and tips as I find them.

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.

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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Copyright © 2013 Delta Numerix

Sunday, 24 February 2013

Raspberry Pi VPN Configuration


This blog entry explained how to setup a PPTPD VPN server on a Raspberry Pi and was based on a blog that is no longer available.

I recently had to install a VPN on another Pi so I thought it was about time to upgrade to the much more secure OpenVPN.

I followed the instructions here :
http://readwrite.com/2014/04/10/raspberry-pi-vpn-tutorial-server-secure-web-browsing
http://readwrite.com/2014/04/11/building-a-raspberry-pi-vpn-part-two-creating-an-encrypted-client-side
These instructions are excellent but I do advise that you proceed slowly because OpenVPN is tricky to setup.

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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Tuesday, 29 January 2013

How To Run A Command On A Remote Unix Machine From Windows

I recently had to create a script under Windows that could kick off a task under Unix. The user of the Windows machine had no knowledge of Unix so I wanted a script or application that I could put on the desktop of the windows machine, that the user could just double click to execute.

I decided to use Strawberry Perl (http://strawberryperl.com/) to execute a script under Windows. After installing Strawberry Perl I installed the perl module Net::SSH2 using the command :
$cpan Net::SSH2
Then I executed the following script :


#!/usr/local/bin/perl

#use strict;
#use warnings;
#use 5.010;  #if you are using version 5.10 or higher

use Net::SSH2;

my $host = "ipaddress";
my $user_id = "username";
my $password = "password";

my ($len, $buf); # Buffer for reading SSH2 output

my $ssh2 = Net::SSH2->new();
$ssh2->connect($host) or die "Unable to connect $host $@ \n";
$ssh2->auth_password($user_id,$password) or die "Unable to login $@ \n";
my $chan = $ssh2->channel();

#Initialize and execute Unix command remotely
$linuxCommand = "ls > output.tmp";
$chan->exec($linuxCommand) or die "Unable to execute the command $@ \n";

sleep (5);


In order to use this script in your application all you need to do is cut and paste the code above into an empty file with the extension .pl (e.g. remoteCommand.pl). Having done this, modify these lines :
my $host = "ipaddress";
my $user_id = "username";
my $password = "password";
(Do not remove the quotation marks)
Then modify this line to change the commande to execute on the remote machine :
$linuxCommand = "ls > output.tmp";
(Put your command between the quotation marks).

Now all you need to do is double click the Perl file and it will execute the command on the remote machine.

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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Copyright © 2013 Delta Numerix

Friday, 18 January 2013

How to benchmark some C code (or assembly code, if you put the assembly in a C callable function)


I often have to benchmark DSP algorithms and while code profiling tools are excellent for large applications, DSP algorithms are often most easily benchmarked using simple timing functions.

Here are two examples that I interchange, depending on the underlying device and/or operating system. These examples are very portable but each solution has its own benefits and disadvantages and the two examples will almost always give different results when executed on the same platform/OS.

This first example uses the clock() function :


#include <stdio.h>
#include <time.h>

#define LOOP_COUNT 1000000000L

void main (void)
{
long i = 0L, j = 0L;

clock_t t_overhead, t_start, t_stop;

/* Calculate the timing overhead */
t_start = clock (); t_stop = clock (); t_overhead = t_stop - t_start;

t_start = clock ();
for (i = 0; i < LOOP_COUNT; i++) { j++; } // Put your code in here
t_stop = clock ();

printf ("Time : %lf seconds\n\n", (((double)(t_stop - t_start - t_overhead)) / CLOCKS_PER_SEC));

}


This example uses the ftime() function :


#include <stdio.h>
#include <sys/timeb.h>

#define LOOP_COUNT 1000000000L

void main (void)
{
long i = 0L, j = 0L;

struct timeb t_current;
long t_overhead, t_start, t_stop;

/* Calculate the timing overhead */
ftime(&t_current); t_start = (long)((t_current.time*1000L)+(long)t_current.millitm);
ftime(&t_current); t_stop = (long)((t_current.time*1000L)+(long)t_current.millitm);
t_overhead = t_stop - t_start;

ftime(&t_current); t_start = (long)((t_current.time*1000L)+(long)t_current.millitm);
for (i = 0; i < LOOP_COUNT; i++) { j++; } // Put your code in here
ftime(&t_current); t_stop = (long)((t_current.time*1000L)+(long)t_current.millitm);

printf ("Time : %lf seconds\n\n", (((double)(t_stop - t_start - t_overhead)) / 1000.));

}

Things to be aware of when using functions like this are :
While it is entirely possible to print times to the nearest ms I suspect that in many applications the values returned by the timing functions are not actually that accurate because underlying everything are a bunch of C functions, libraries and an OS.
When calling your processing function on a multi-tasking OS you have little or no control about what else the OS is doing in the background.
The clock function returns values that depend on the implementation
On some processors it returns 0 the first time it is called and then starts incrementing
On some processors it starts counting when the process starts
On some processors it counts in milliseconds
On some embedded processors (e.g. some DSPs I have programmed) clock () does not return the time in seconds but cycles of the processor.
You should always use CLOCKS_PER_SEC to turn this value into real time
The clock() function is more commonly implemented on embedded processors than the ftime() function.
If the function to be benchmarked is very short then it may be necessary to call it a number of times to average out the effects of the OS and the accuracy of the clock functions.

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.

Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/

Copyright © 2013 Delta Numerix