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.
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.
Sunday, 9 October 2016
Monday, 4 July 2016
Updated Numerix Host Library
The Numerix Host Library is a library of C/C++ functions that can be used to write DSP data to files for debugging, logging and exchange between different applications such as SigLib, Matlab, Octave, Open Office, Libre Office, Excel, Python and others.
It currently supports .bin .csv, ,dat (gnuplot), .sig (SigLib), XMOS .xmt and .wav file formats.
Numerix Host Library can be downloaded from here.
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.
It currently supports .bin .csv, ,dat (gnuplot), .sig (SigLib), XMOS .xmt and .wav file formats.
Numerix Host Library can be downloaded from here.
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.
Friday, 3 June 2016
DSP Tech Brief : Frequency Domain Convolution And Filtering
Performing convolution and filtering in the frequency domain is a useful method of increasing the performance of these functions by using the fact that convolution in the time domain is equivalent to multiplication in the frequency domain.
The down side is that there is increased end-to-end latency due to the requirement to translate between the time and frequency domains (and back again).
Two common methods of performing this task are the Overlap And Add or the Overlap And Save.
These algorithms are summarized in the following document : http://www.numerix-dsp.com/tutorials/DSP/FrequencyDomainFiltering.pdf
Some notes to accompany the presentation :
Looking at the diagrams, lets assign the filter input to Input A and the streaming data to Input B.
The FFT for the filter input can be pre-calculated to reduce the run-time overhead.
The filter length is defined by the system level requirements - pass band ripple, stop band attenuation, transition bandwidth. From this you can then work out what FFT length (> length N+M-1) you require, what dataset length you can support (Input B) and then what overlap you need to use for the FFT algorithms.
If you use Decimation In Frequency algorithms for the forward and inverse FFTs then you can avoid the need to bit reverse re-order the data because all of the frequency domain data will be in bit reversed order.
When using an FFT for an application such as spectrum analysis it is often necessary to window the time domain data to reduce spectral leakage. This is not necessary for the overlap algorithms because the spectral leakage is a linear (convolution) operation caused by the discrete nature of the forward FFT. When you perform the inverse FFT the process is reversed and hence the effect is cancelled
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.
The down side is that there is increased end-to-end latency due to the requirement to translate between the time and frequency domains (and back again).
Two common methods of performing this task are the Overlap And Add or the Overlap And Save.
These algorithms are summarized in the following document : http://www.numerix-dsp.com/tutorials/DSP/FrequencyDomainFiltering.pdf
Some notes to accompany the presentation :
Looking at the diagrams, lets assign the filter input to Input A and the streaming data to Input B.
The FFT for the filter input can be pre-calculated to reduce the run-time overhead.
The filter length is defined by the system level requirements - pass band ripple, stop band attenuation, transition bandwidth. From this you can then work out what FFT length (> length N+M-1) you require, what dataset length you can support (Input B) and then what overlap you need to use for the FFT algorithms.
If you use Decimation In Frequency algorithms for the forward and inverse FFTs then you can avoid the need to bit reverse re-order the data because all of the frequency domain data will be in bit reversed order.
When using an FFT for an application such as spectrum analysis it is often necessary to window the time domain data to reduce spectral leakage. This is not necessary for the overlap algorithms because the spectral leakage is a linear (convolution) operation caused by the discrete nature of the forward FFT. When you perform the inverse FFT the process is reversed and hence the effect is cancelled
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.
Sunday, 3 January 2016
VMWare Virtual Machine Notes
I need somewhere to store my notes so this seems to be as good a place as any.
How To Remove Old Ubuntu Kernel Packages
Stolen from my Brother here : https://edwards.sdsu.edu/research/ubuntu-clean-boot-partition/#more-1599
First, figure out which running kernel you have:
uname -r
Do NOT remove that kernel!
Figure out which kernels you have installed
dpkg -l | grep linux-image | grep ii
Then remove them:
apt-get autoremove <package 1> <package 2>
Shrinking Virtual Machines To Use Less Disk Space
In virtual machine :
sudo apt-get -y autoremove
sudo apt-get clean
cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill
Download vdiskmanager-windows from here :
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023856
On the host :
vmware-vdiskmanager -k Ubuntu.vmdk
Numerix-DSP Libraries : http://www.numerix-dsp.com/eval/
How To Remove Old Ubuntu Kernel Packages
Stolen from my Brother here : https://edwards.sdsu.edu/research/ubuntu-clean-boot-partition/#more-1599
First, figure out which running kernel you have:
uname -r
Do NOT remove that kernel!
Figure out which kernels you have installed
dpkg -l | grep linux-image | grep ii
Then remove them:
apt-get autoremove <package 1> <package 2>
Shrinking Virtual Machines To Use Less Disk Space
In virtual machine :
sudo apt-get -y autoremove
sudo apt-get clean
cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill
Download vdiskmanager-windows from here :
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023856
On the host :
vmware-vdiskmanager -k Ubuntu.vmdk
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 © 2017 Delta Numerix
Sunday, 30 August 2015
DSP Tech Brief : Why Use A High Level Language For DSP ?
The field of Digital Signal Processing is constantly pushing the price / performance envelope of technology and traditionally this has required systems developers to use assembly language for the majority of the time critical signal processing routines. Today's commercial pressures have moved the "goal-posts" dramatically and typical project development timescales require a larger part of the application to be developed using a high level language. Another benefit to using a high level language for the system development is that a system can be rapidly prototyped to prove the algorithms and then hand optimised using assembly code for the time critical areas.
The latest generation of compilers allows high level code to be compiled to a quality of assembly code that is very close to that which would be generated by hand. The development process is therefore very much easier than writing the algorithm in assembly code from scratch. An increasingly common development route is to develop the algorithms on a PC or Workstation and then rewrite the application for the target processor. Using the same language for development and deployment often allows the same code to be used for both, with the different I/O requirements handled through the use of conditional compilation of the source.
Modern high performance DSPs are also changing the way we view algorithmic efficiency and an increasing number of projects are written in a high level language because the savings at development time are far greater than the extra cost overhead of using faster processors at deployment.The architectures of the latest DSPs are also becoming more complex, for example with the integration of parallel execution units. This means that it is increasingly difficult for programmers to learn how to fully optimise their algorithms. When the complexity issue is coupled with the fact that the majority of DSP algorithms are block oriented vector processing algorithms and it is now becoming possible for high level language compilers to produce code that is 100% optimised.
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.
Primary Reasons For Using High Level Languages
- High productivity
- Portability
- Maintainability
- Code reuse
- Optimising system cost / performance
- Rapid prototyping and algorithm proving
- Integration with real-time kernels and operating systems
- Ease of debug
- Availability of algorithms
The latest generation of compilers allows high level code to be compiled to a quality of assembly code that is very close to that which would be generated by hand. The development process is therefore very much easier than writing the algorithm in assembly code from scratch. An increasingly common development route is to develop the algorithms on a PC or Workstation and then rewrite the application for the target processor. Using the same language for development and deployment often allows the same code to be used for both, with the different I/O requirements handled through the use of conditional compilation of the source.
Modern high performance DSPs are also changing the way we view algorithmic efficiency and an increasing number of projects are written in a high level language because the savings at development time are far greater than the extra cost overhead of using faster processors at deployment.The architectures of the latest DSPs are also becoming more complex, for example with the integration of parallel execution units. This means that it is increasingly difficult for programmers to learn how to fully optimise their algorithms. When the complexity issue is coupled with the fact that the majority of DSP algorithms are block oriented vector processing algorithms and it is now becoming possible for high level language compilers to produce code that is 100% optimised.
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.
DSP Tech Brief : The Zoom-FFT
The Zoom-FFT is a process where an input signal is mixed down to baseband and then decimated, prior to passing it into a standard FFT. The advantage is for example that if you have a sample rate of 10 MHz and require at least 10Hz resolution over a small frequency band (say 1 KHz) then you do not need a 1 Mega point FFT, just decimate by a factor of 4096 and use a 256 point FFT which is obviously quicker.
Advantages of the Zoom FFT are :
Applications of the Zoom FFT include :
The following diagram shows the zoom process :
While the following diagram shows the basic architecture of the Zoom-FFT :
One common question is : Is the zoom FFT the same as the chirp z-transform.
The answer is : Absolutely not. The FFT calculates the FFT at N equally spaced points around the unit circle in the z-plane, the chirp z-transform modifies the locations of these points along a contour that can lie anywhere on the z-plane. In contrast, the zoom-FFT uses digital down conversion techniques to localise the standard FFT to a narrow band of frequencies that are centered on a higher frequency. The chirp z-transform is often used to analyze signals such as speech, that have certain frequency domain charactgeristics. The zoom-FFT is used to reduce the sample rate required when analysing narrowband signals - E.G. in HF communications.
These functions, and more, are available in the SigLib DSP Library.
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.
Advantages of the Zoom FFT are :
- Increased frequency domain resolution
- Reduced hardware cost and complexity
- Wider spectral range
Applications of the Zoom FFT include :
- Ultrasonic blood flow analysis
- R.F. communications
- Mechanical stress analysis
- Doppler radar
The following diagram shows the zoom process :
One common question is : Is the zoom FFT the same as the chirp z-transform.
The answer is : Absolutely not. The FFT calculates the FFT at N equally spaced points around the unit circle in the z-plane, the chirp z-transform modifies the locations of these points along a contour that can lie anywhere on the z-plane. In contrast, the zoom-FFT uses digital down conversion techniques to localise the standard FFT to a narrow band of frequencies that are centered on a higher frequency. The chirp z-transform is often used to analyze signals such as speech, that have certain frequency domain charactgeristics. The zoom-FFT is used to reduce the sample rate required when analysing narrowband signals - E.G. in HF communications.
These functions, and more, are available in the SigLib DSP Library.
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.
DSP Tech Brief : Signal Scrambling And Linear Feedback Shift Registers (LFSRs)
Modulated signals are often scrambled when they are modulated. There are many reasons for scrambling the signal, including : spreading the spectrum and reducing the correlation between separate channels. Most scramblers utilise a Maximum Length Pseudo-Random Binary Sequence (MLPRBS or MLS), this uses a shift register an exclusive-or gates to randomise the data, as shown in the following diagrams. There are two general arrangements for implementing a scrambler, the non-synchronising and the self-synchronising types, each has its own benefits and draw backs, the non-synchronising type requires that the transmitter and receiver are synchronised before data transmission starts however once synchronised an input bit error to the receive scrambler will cause a single bit error in the output. The self-synchronising scrambler(shown below), as the name suggests will automatically synchronise to the received bit stream but a single receive bit error will cause N+1 bit errors in the output stream, where N is the length of the shift register.
This algorithm is included in the SigLib DSP Library.
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.
This algorithm is included in the SigLib DSP Library.
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.
Subscribe to:
Posts (Atom)