Help designing-in fast ADC (e.g. Analog Devices AD7761) for sonar.

GoogleGroups
1

Hi

I’m new to BB but not new to hardware/software engineering. My reason for posting is that I am struggling to connect it to the Beaglebone in a way that permits fast data capture, and I am hoping that someone might be able to offer suggestions.

My (hobby) idea is to create a device that can read 6 to 8 channel audio and use sonar data analysis such as audio beamforming to analyse environmental sound, in the first instance to identify the direction sounds are coming from: https://en.wikipedia.org/wiki/Acoustic_source_localization

I have been looking to use a high-speed ADC such as the £12 AD7761 - an 8 channel, 16-bit true simultaneous sampling converter capable of 100HKz sampling, which uses SPI for device control but a much simpler serial data channel (using 1, 2 or 8 lines) for the analog samples. The max audio data rate is thus approx 12MBits/s sustained (96KHz sample rate). However, each 16-bit sample on the 7761 is output as a 24-bit value, with the 8 additional bits including channel/sample metadata. Thus the device-level data rate is around 18.5MBits/s for all 8 channels. The recommended Data I/O clock rate for the device is, however, 32.6MHz. Although it will work slower, there are impacts elsewhere.

The device has 8 serial output data lines and a sync line indicating start of the 24-bit data frame on the data lines. The next sample (either next channel or next in time, depending on configured # channels and outputs) follows on immediately. The device can either interleave all sample data on 1 line, split it across 2 lines, or use 1 dedicated line per channel. Byte-parallel output is not possible.

Something like:

DS ____---__
Ch1 ____XyyyyyXyyyyyXyy

…
ChN ____XyyyyyXyyyyyXyy

X=first bit of frame, y=other bits in frame.

Ideally I was hoping that I could use a PRU to read the data stream, so that the host ARM-8 could be left running the analysis software in peace. The analysis will involve performing continuous FFTs or similar so the A8 won’t be idle! Ideally the PRU will move the channel data into pre-allocated host memory buffers, one buffer per channel, so that the host can do its stuff. I’m thinking something like a DMA-based Ethernet chip works.

Initially I hoped to use the GPIO pins for serial or byte-parallel input:

  • I don’t think even a PRU can ‘bit-bang’ the port fast enough to work at even 20MHz, let alone 32MHz.

  • I cannot see a way of using the 28-bit serial input(s) on the BB: the pin seems to be in use by the BB, and even if available, how can I only grab 24 bit not 28 bit data, and take note of the DS line? Very curious as to why this port is not 32 bit and triggered more flexibly.

  • Byte-parallel input would help with data rate issues but I cannot seem to find a group of 8 sequential pins on the same PRU input port other than the LCD pins, which seem to be needed for HDMI output. If that could be sorted at one point I was thinking of reading 4 bytes of 6 bits at a time and using the 2 bits per byte as a counter, so as to ensure the PRU remains in sync with the stream. I would much prefer not to, but HDMI/LCD could be sacrificed.

  • I looked at using a dedicated chip: of these the 74HC673 16-bit serial-parallel converter looked very helpful, but I wasn’t sure how to read 16-bits then 8 bits at a time and retain sync, and again, which 16 lines can be read by a single 16-bit PRU read?

  • I looked into FPGA use, and still think that would probably work and may even offer some real advantages, but the assembled LOGI-bone uses an obsolete FPGA and is expensive, the LOGI-bone 2 is even more so, and though a cheap 44-pin FPGA is not, there is still quite a bit of faff getting it connected and programmed. If an FPGA were the answer I would like to implement a small (8-word?) FIFO in it, but otherwise it’s job would mainly be to interface the ADC to the Sitara.

  • I keep wondering about SPI, but I need one Sitara SPI channel for the ADCs own use of SPI and I know the BB uses one Sitara SPI channel itself; I think that leaves one channel left. Could the BB SPI (even if I can convert the data stream properly) handle data at ~ 20Mbits/sec including protocol overheads?

Any thoughts/advice gratefully accepted!

Ruth

2

Perhaps you should be thinking of using an external dedicated processor for your application ? Something that has decent on die ADCs. Something like the TI C2000 line ?

There are many dev kits here which include but are not limited to just the C2000 products: http://www.ti.com/lsds/ti/tools-software/launchpads/launchpads.page

If one of those processors / dev kits would be good enough, then the problem just becomes how to get that data over to the Beaglebone. Assuming a Beaglebone would still be required.

As far as the PRUs go. There is a project on github called “BeagleLogic” that claims to be able to Sample up to 14 channels, 8-16bit data, at 10-100Mhz. So maybe you could sift through the project information, and source code to maybe figure out a way to make what you want to do - Work.

3

Ruth

I would suggest that you look at the MCASP peripheral feature on the Beaglebone Sitara processor.

See “AM335x Technical Reference Manual”, Chapter 22

There are two of them, and each is a multi-channel audio interface.

It looks like your AD7761 can be configured to run serial wire per channel, two four channel TDM or one eight channel TDM.

Each MCASP can be configured as four channel, one data wire per channel parallel interface, or in TDM mode each can be configured for either four or eight channel 24 or 32 bit serial.

So, it seems that one MCASP should be able to deal with the AD7761 ADC, and you would have multiple options as to how to configure the interface, using two MCASP periherals.

You would have to make sure that all the wires you would need are pinned out from the Sitara to one of the headers, where you could get at them, as well as there are no conflicts for each of those pins, as to other things you expect the Beaglebone to be doing.

You would need to investigate the availability of a configurable driver, or worst case, write your own custom driver.

You are talking about streaming a lot of data, so likely only a modest amount of signal processing can be done on the Sitara in real time.

— Graham

4

Hi

William: Unfortunately the TI chips I found on the launchpads page have multichannel interfaces, but not simultaneous: that is there is only one actual ADC and multiple Sample/Hold units. In the application I’m interested in, sampling truly simultaneously is one of the requirements.

Graham: Thanks for that; I hadn’t considered that the McASP might be able to read as well as write data streams, but I guess it does make sense. I’ll have a look.

I did things like this in the past on Sun-4 workstations at 200MHz, though only 1/4 real time. Hoping that an ARM-8 with SIMD extensions will be able to do it real-time :slight_smile:

Regards
Ruth

5

The ADC can be set up to run audio format TDM. You have two MCASP, which are high speed multi-channel TDM engines to play with.

(Although I think they only did a real good job of pinning out MCASP0, need to investigate, but one might be enough.)

Each are relatively independent bi-directional.

Curious as to why you need outbound TDM, If for configuring the part, use a SPI peripheral for that.

One question is if you can find a Linux driver that can be configured the way you need it.

Without an on-board DSP, beware of the amount of number crunching you can do, at the same time you are moving around that much data.

A DaVinci processor, which is basically a Sitara plus a C67 DSP would have a lot more DSP capability, or the newer Keystone series processors.

The Beagleboard X-15 is probably more like what you will need, if you are going to do a lot of signal processing.

— Graham

6

Graham, thanks for your thoughts, sorry for delayed reply.
I am hoping that the Arm chip can cope with the data ratre involved, certainly it will be a challenge. The tdm audio out thing was only that I do want HDMI video out, and didn’t want its possible audio use to interfere with tdm input.

The X-15 would be higher on my list but it’s a trifle expensive :frowning: hope I don’t have to get one anyway :slight_smile:

Ruth