Help me design a board for DSP!

[SethGI]

Hello,

This is my first post on the forum, and I'm about as much of a noob to pcb design as I am to the forum   I'm working on an underwater robotics project that requires the robot to be able to track an acoustic pinger using a sonar array of four hydrophones (underwater microphones). I need to design a board to input and amplify the audio signals, do some basic filtering and conditioning, convert from analog to digital, and then send the digital data off to a computer for processing. I am posting looking for help with the general flow of the circuit... I'm not looking for specific components or anything. This is what I have so far:

Hydrophones -> Amplifier circuit -> bandpass filters -> ADC -> -> computer.

The bit I'm stuck at is how to get the data from the ADC to the computer. I have a few ideas, but their all bad and won't work so I won't waste your time listing them. I can communicate via I2C and USB. Any thoughts? Thanks for the help!

[cncjerry]

ADC>>Arduino,etc>>VCP over USB>>PC.

VCP is virtual com port.  Arduino, STM, just about all of the micros support VCP over USB.  And if your ADC isn't that complicated, an STM32F4 can probably replace the ADC and do the communications with the PC as well.

[SethGI]

ADC>>Arduino,etc>>VCP over USB>>PC.

VCP is virtual com port.  Arduino, STM, just about all of the micros support VCP over USB.  And if your ADC isn't that complicated, an STM32F4 can probably replace the ADC and do the communications with the PC as well.

Thanks for the response. I considered using an arduino... but the issue is I want to be processing all of the signals on the computer, and I think it's a bit excessive to have an entire arduino just to send the signals over to the PC. Maybe there's a way to incorporate a VCP into the circuit directly? I would love to have it all on a single board. I'd rather not have any processors embedded on the board, but maybe I have to.

[NiHaoMike]

Use a Raspberry Pi and send the data over Ethernet? You can even run the Ethernet over two wires using a hacked pair of Homeplug adapters in order to simplify the problem of waterproofing the wiring.

[bobaruni]

The easy way would be to just use a 4ch USB sound card (one that can do simultaneous sampling of all 4 channels) and write some software on the PC side to capture the stream and process it further.
You might need some amplification before the sound card, a good audio grade quad op-amp will do but you could probably get away with all of the filtering using DSP on the PC side.
What sort of frequency are you looking at for the sonar signals?

[Kalvin]

Unfortunately Arduino is not an option in this case as it is definitely too slow.

There are some options:

- Use a 4-channel, high quality 24-bit audio CODEC with synchronous sampling (all channels are sampled at the same instant), at least 192kHz sample rate and make sure the phase information is not corrupted in the process. If the channels are not sample synchronously, you need to compensate the sampling difference in the later processing. Just make sure that the sampling instants do not have any significant jitter.

- Connect the a high quality, 4-channel audio CODEC to a real DSP and stream the data over Ethernet to a desktop computer for actual processing. You can perform some initial processing in the DSP if needed in order to offload some computations from the desktop computer.

- Connect the a high quality, 4-channel audio CODEC to a Raspberry Pi and stream the data over Ethernet to a desktop computer for actual processing.

- Get yourself a good audio card for your laptop / desktop machine and capture the data using the audio card and perform the processing in the same machine. You need a fast machine, though.

I would go for the last option first in order to evaluate the initial system performance and analysis and for the basic algorithm development. After that I would consider the second option as it should not be too difficult to hook a audio CODEC to Raspberry Pi and make it stream the data over Ethernet. I would save the DSP option last, because it requires much more effort in order to get the DSP up and running, and performing the Ethernet streaming. However, the DSP option is a good one in performance / power wise.
 

[Kalvin]

Hydrophones -> Amplifier circuit -> bandpass filters -> ADC -> -> computer.

If possible, do not use the analog bandpass filters before the ADC as the filters will distort the phase information. Instead of analog filtering use digital bandpass FIR-filters after the ADC. The FIR filters have constant delay which preserves the phase information. If the bandpass filter needs to be very steep, you may need to make it IIR, but the IIR filters will distort the phase information. However, there are few tricks that you can do in order to preserve the phase information in the IIR filters ie. time-reversal: http://www.embedded.com/design/configurable-systems/4008847/DSP-Tricks-Doing-Zero-phase-filtering

[2N3055]

Beaglebone black... There is a published whitepaper using ads1271 and it for sonar.. Maybe you can contact these guys and ask them .. 

[danadak]

Cypress PSOC 5LP family has DSP, ADC (2, SAR, DelSig), lots of COM,
lots of linear, REF, OpAmp, Comparator, Mixer, ARM Core, routable,
GUI design tool, see attached. DMA that does tasks in background. LCD
to drive displays........

Tons of code and examples. Lots of training videos....

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc



Regards, Dana.

[SethGI]

Unfortunately Arduino is not an option in this case as it is definitely too slow.

There are some options:

- Use a 4-channel, high quality 24-bit audio CODEC with synchronous sampling (all channels are sampled at the same instant), at least 192kHz sample rate and make sure the phase information is not corrupted in the process. If the channels are not sample synchronously, you need to compensate the sampling difference in the later processing. Just make sure that the sampling instants do not have any significant jitter.

- Connect the a high quality, 4-channel audio CODEC to a real DSP and stream the data over Ethernet to a desktop computer for actual processing. You can perform some initial processing in the DSP if needed in order to offload some computations from the desktop computer.

- Connect the a high quality, 4-channel audio CODEC to a Raspberry Pi and stream the data over Ethernet to a desktop computer for actual processing.

- Get yourself a good audio card for your laptop / desktop machine and capture the data using the audio card and perform the processing in the same machine. You need a fast machine, though.

I would go for the last option first in order to evaluate the initial system performance and analysis and for the basic algorithm development. After that I would consider the second option as it should not be too difficult to hook a audio CODEC to Raspberry Pi and make it stream the data over Ethernet. I would save the DSP option last, because it requires much more effort in order to get the DSP up and running, and performing the Ethernet streaming. However, the DSP option is a good one in performance / power wise.

Thanks for the advice. I am wondering why you wouldn't just go with option 1... seems the simplest. I could use solution 3 or something like it to process the data. I found this http://www.ti.com/lit/ds/symlink/pcm3168a.pdf which has adcs built in, as well as I2C to communicate with a board like the raspberry pi, beaglebone, odroid, etc. Would that be a good solution? Also, I can't tell if I2c would be able to communicate all of the data from four separate outputs. Thoughts? Thanks again for th ehelp.

[nctnico]

If the frequency band is narrow you can undersample (after band filtering the analog signal) and send that to the PC. For an ultrasonic project with the transducers in the 40kHz range I sampled at 15kHz. When undersampling the driving factor becomes the required bandwidth and the duration of the pulses (how many cycles do you get at the samplerate).

[whollender]

No one has come right out and said it yet, but you should probably start with existing components (eval boards, etc) before diving into the full design.  That way you can explore the limitations of a given approach before spending a lot of time on it.

I agree with Kalvin that a good place to start is with a 24 bit, 4 channel audio codec (or just an ADC, because it sounds like you won't need any outputs).  Most of these use an I2S interface to communicate with the host, with an additional I2C bus for configuration (I2C is not generally fast enough for audio rate data).

I designed a stereo audio board that's compatible with a variety of hosts (https://hackaday.io/project/5912-teensy-super-audio-board), but it only has 2 inputs.  This project extended it using a multi-channel codec (2 stereo input channels, 4 stereo outputs) (https://hackaday.io/project/9634-linux-based-low-latency-multichannel-audio-system), but it's only compatible with BeagleBone Black.

If you are restricted to using a USB uplink to a PC host, you can explore using a small micro to communicate with the audio codec/adc, and then send it upstream to the PC using a USB audio link.  I know that there was some work to get something like that working on the Teensy (pjrc.com).  The Teensy even has working quad input I2S using Paul's audio boards (https://www.sparkfun.com/news/2055).  Doing quad input I2S at 192kHz is probably outside of the capabilities of a Teensy 3.x, however.

If you don't want to go the microprocessor, or RPi route, there are ICs available that act as a bridge between an I2S interface and a USB audio interface.

[SethGI]

No one has come right out and said it yet, but you should probably start with existing components (eval boards, etc) before diving into the full design.  That way you can explore the limitations of a given approach before spending a lot of time on it.

I agree with Kalvin that a good place to start is with a 24 bit, 4 channel audio codec (or just an ADC, because it sounds like you won't need any outputs).  Most of these use an I2S interface to communicate with the host, with an additional I2C bus for configuration (I2C is not generally fast enough for audio rate data).

I designed a stereo audio board that's compatible with a variety of hosts (https://hackaday.io/project/5912-teensy-super-audio-board), but it only has 2 inputs.  This project extended it using a multi-channel codec (2 stereo input channels, 4 stereo outputs) (https://hackaday.io/project/9634-linux-based-low-latency-multichannel-audio-system), but it's only compatible with BeagleBone Black.

If you are restricted to using a USB uplink to a PC host, you can explore using a small micro to communicate with the audio codec/adc, and then send it upstream to the PC using a USB audio link.  I know that there was some work to get something like that working on the Teensy (pjrc.com).  The Teensy even has working quad input I2S using Paul's audio boards (https://www.sparkfun.com/news/2055).  Doing quad input I2S at 192kHz is probably outside of the capabilities of a Teensy 3.x, however.

If you don't want to go the microprocessor, or RPi route, there are ICs available that act as a bridge between an I2S interface and a USB audio interface.

The plan is definitely to start with existing components... I just want to have a general plan first so the equipment I start with is similar enough hardware so when I'm developing software and working on everything and integration it won't be a huge pain in the ass to switch over to a fully custom design. I'm just exploring my options and learning as much as I can!

Thanks for the help!