DSP - recommendations for up to 150kHz, several  bandpass filters needed - Page 1
Forum section: electronics / general

author: robinaspey
author_rank: Newbie
timestamp: September 12, 2016, 07:45:58 pm
content: Hi DSP folks,I have no experience with dedicated DSP and the most I have done is implement windowed moving averages filters forPIC and AVR. I have various embedded experience but nothing with dedicated DSP.My next project will be sonar. I am wanting to monitor dolphin and whale communications which will require monitoringa number of frequency bands for different characteristics such as ranging and their normal chitchat. The long range frequencieswill be as low as 20Hz and the highest frequencies will be 150KHz for ranging.Basically I will need to monitor in parallel to do an assessment with a range of DSP filters that I can change the centerfrequency and width of bandpass. There are other aspects as will be explained.I expect to get the least phase distortion so an FIR would be best. So this leads me to what hardware (processor type oreven FPGA) might be best. If it could be done on an FPGA to have several parallel channels that would be great althoughwith little experience in DSP I am expecting a TMS320 variant will be best for FIR up to 150kHz.The polynomial filter coefficients may also need to change dynamically. For example I may want a search function where a channelscans continually and then on finding a signal it sets the filter coefficients for center frequency and channel width to startrecording on a channel using a parallel DSP. It then continues to scan to survey the available signals within its range.Anyone with recommendations for a DSP (ideally low-power) and whether this could be done in FPGA... all comments welcomeeven if not entirely complementary of my DSP knowledge or lack of it.The DSP will also need to be able to write to a micro SD card, and I would also like D/A output to help test the filters. Onemore item I would like is the ability to store FFT/DFT profiles over a time window to characterise the signals obtained overdifferent pass bands.A lot to ask but I need to start somewhere, ideally with the right hardware.RegardsRob

author: mark03
author_rank: Frequent Contributor
timestamp: September 14, 2016, 06:21:17 pm
content: Embedded DSP is hard. I mean, it's great, but, you don't want to go in without the desired algorithms nailed down. If you haven't done a great deal of offline experimentation in MATLAB, NumPy, or similar, I would focus on that until you feel confident about the processing you'd like to implement. It's going to be way easier to take some recordings at N-hundred-kHz sample rate and then play with those on a PC than it will be to experiment on the fly in an embedded implementation. Doubly so if, as you indicate, you're still coming up to speed on the DSP theory. This stuff is hard enough to figure out in MATLAB without troubleshooting a buggy C / asm / HDL implementation at the same time.

author: AndyC_772
author_rank: Super Contributor
timestamp: September 14, 2016, 07:41:29 pm
content: I think you're definitely thinking along the right lines.How many FIR taps do you anticipate needing, and how many filters do you expect to need to run simultaneously? That'll give some idea of the processing capability needed, and will help choose an appropriate platform.I've designed several boards with TMS320Cxxxx devices. They're not trivial to use, and the older ones are anything but low power. They're undeniably powerful, but take quite a lot of work to get up and running, and programming one to run efficiently (ie. actually achieve anything approaching the advertised speed) is a skill in its own right. I'm not sure I'd recommend one unless you have a confident design engineer available to make it live and breathe.Personally I like the combination of a general purpose MCU (eg. an ARM Cortex M4) plus an FPGA for this kind of thing. The FPGA is an excellent choice for driving an ADC and performing repetitive mathematical operations on sampled data, and the MCU does the higher level stuff like storing data, communicating with the outside world, and making complex decisions about what the data from the ADCs actually means.

author: nctnico
author_rank: Super Contributor
timestamp: September 14, 2016, 08:58:40 pm
content: I second the suggestion for prototyping the algorithmes on a PC first because verification is key in digital signal processing chains. Being able to load a known dataset into a processing chain and checking the output will be a huge help so the design should accomodate for this even though it takes extra design effort and components on a prototype.

author: Howardlong
author_rank: Super Contributor
timestamp: September 14, 2016, 10:12:07 pm
content: Yes I agree definitely get the algorithms working on the PC first, then port them as-is first, and then optimise.There is plenty of tweaking that can be done, and depending on processor that will be done in different ways, and almost all solutions will implementation specific and a good knowledge of the target device. This often doesn't mean digging into assembly but it does occasionally. Typically understanding the on chip registers, cache, wait states, pipeline stalling, VLIW, bus arbitration, loop unrolling, the use of compiler idioms, and intrinsic functions, it's not uncommon to gain an order of magnitude in speed over an unoptimised vanilla algorithm.One recommendation if you're a newbie is to go for a processor that offers single cycle floating point operations, although there is a power consumption tax on that. Some of the TI VLIW processors will do several floating point operations simultaneously if you can structure and code your algorithm around it: typically this involves pipelining mutually exclusive operations, which in itself often makes for pretty unreadable code: I usually always keep my readable working but unoptimised code in there, commented or #ifdef'd out, for documentation and sanity/cross checking purposes.Using pre baked optimised vendor provided libraries is usually a good start, but keep in mind a few examples aren't very good, for example some of the ARM CMSIS DSP FIR filter code isn't well optimised at all at the algorithm level.

author: robinaspey
author_rank: Newbie
timestamp: September 16, 2016, 05:52:48 pm
content: Thanks for all of the responses, and I agree I will need to do some more work with Matlab.I have worked through a few examples based on youtube (yep - I know cheating) as I have not used Matlab a lot in recent years and as a refresher its clear my memory of the theory of this is fairly intact. Now to put it into practice.What would REALLY help is a source of code examples for things like notch filters for a decent TMS320 variant - ideally viaa development board.I'm fairly good at embedded so the bits I need to nail down are to compile some decent examples for filters on a specific (ideally low powerDSP - TMS320 variant) and then modify based on the outcomes of my simulations with Matlab.As it would be really good to see the output of the filter in analogue real time format - does anyone have any suggestions for a fairly lowpower DSP kit that already has a DAC output - ideally more than one.?I'm currently leaning towards the C2000 piccolo , but it does not seem to have DAC. The TMS320 seem to have PWM as a proxy forDAC for motor control.http://www.ti.com/lit/ml/sprt547/sprt547.pdfAny comments on this? I will need to interface to a DAC board I believe, so this looks like it may work with the headers.Its a fairly long term project so one issue I need to consider is not committing to a learning curve, on something that may proveto be inadequate and then to have to go onto another learning curve so if this one will work e.g. C2000 piccolo thats great.I am expecting a horrible learning curve (always best to be realistic) but that I am ok with, its making the choice of the rightfamily and hardware specific items so as not to have to duplicate effort later on something else.If there are limitations it would help to have experienced persons comment.RegardsRob

author: scatha
author_rank: Regular Contributor
timestamp: September 17, 2016, 03:35:03 am
content: Before you start out make sure you do a literature search if you haven't done so already. Whale communications is notoriously resistant to traditional DSP analysis given the waveform operates over so many different time scales and can be very dynamic. Wavelet transforms are pretty popular in this space as they allow you to localise the vocalization in both time and frequency.

author: nctnico
author_rank: Super Contributor
timestamp: September 17, 2016, 06:14:11 am
content: I don't see any space or power constraints: how about using a (fast) PC to do the processing and use a data acquisition board to get the analog signal(s) into the PC? When it comes to processing power a PC offers vasts amounts for little money and it is also a very easy development platform. If the CPU doesn't cut it, move over to CUDA.

author: diyaudio
author_rank: Frequent Contributor
timestamp: September 17, 2016, 07:28:10 am
content: Look at the new SHARC product line from Analog Devices.

author: robinaspey
author_rank: Newbie
timestamp: September 17, 2016, 01:07:09 pm
content: My literature review so far seems to indicate FPGA with floating point may be a way forward. Does anyone have any experience with floating point FPGA and are there any lower end devices that may work with floating point?Regardsrob

author: filssavi
author_rank: Frequent Contributor
timestamp: September 17, 2016, 03:27:44 pm
content: Typically FPGA embedded DSP blocks are fixed point and i'm unaware of anything in Xilinx products line that has hardware floating point supportWith that said the beauty of FPGA's is that if you really need floating support it should not be too terribly difficult to wrap the integer dsp core in a floating point normalization layer (basically shift the mantissa left or right until the expoments are equal, calculate and normalize at the end)

author: nctnico
author_rank: Super Contributor
timestamp: September 17, 2016, 07:52:24 pm
content: Xilinx has a floating point library but I'd go for a PC solution first as a demonstration model and anchor point for miniaturisation. I doubt this project will be succesfull if the PC version is skipped.http://www.xilinx.com/products/intellectual-property/floating_pt.html

author: znroot
author_rank: Contributor
timestamp: September 18, 2016, 05:43:38 am
content: I used the TMS320F28377S for a DC-DC converter digital control. It has several peripherals and a floating point unit useful for real-time applications.Thanks to the 200MHz main cpu clock it can be used to do real-time filter. But pay attention that you may have to write the filter code in assembly for high performanceBut if you need several filters you need a FPGA!

author: John_at_Entegra_Solutions
author_rank: Newbie
timestamp: September 20, 2016, 11:03:33 am
content: Hi Robin,You may of come across the Zynq family of FPGA devices from Xilinx. These are in the SoC (System on a Chip) family which gives you a chip which has dual ARM processor cores and a lot of FPGA gates that can be programmed to perform DSP functions. If you used a Zynq based board then you can divide your algorithm between C/C++ code running on a processor core and FPGA resources. In the C/C++ code you can do the slower and complex parts of the algorithm and in the FPGA you can do the simple, repetitive parts such as FIR filters. I agree with the others that you need to chose your algorithms first, run them on a PC to see what is practical and then find a hardware target.We represent Innovative Integration Inc in the UK and they have a family of Zynq based boards plus analogue IO. I suggest you look at Cardsharphttp://www.innovative-dsp.com/products.php?product=Cardsharpand FMC-Servohttp://www.innovative-dsp.com/products.php?product=FMC-ServoThe 2nd CPU in the Zynq is there for I/O to ethernet, USB, embedded Flash etc.You can contact me by email or via the Innovative distributor list if you need further information. Good luck with your research.

author: rsjsouza
author_rank: Super Contributor
timestamp: September 21, 2016, 04:19:54 pm
content: Simultaneous filters with floating point support can be had in the C66x family of DSPs from TI, but they are not low-power. In any case, you have pre-built FIR functions in theDSPLIB packageand other functions in theMATHLIB package. For device drivers, etc. you can use theProcessor SDK RTOS.Depending on the number of filters you need FPGAs and ARMs will not be low power as well, but I am not familiar with signal processing packages for these architectures.