interfacing an ADC (LTC1408-12) with PC

On Wednesday, 10 September 2014 20:01:06 UTC+3, snipped-for-privacy@gmail.com wrote :

e transform) on those signals gathered by the mics in order to obtain the time delay between each pair of mics and find the direction of sound arriv al in 3D and steer a camera to that direction.

nd an angle is ...

7 inches of delay. you may need to place your mikes at 'wide' locations, b ecause close up more accurate than if the subject is 15 feet away

dentify the interesting time frame, you probably need higher resolution sam plings. Assuming that you also have some servo controlling of the camera, you have a very tight control loop. Doing it with PC/laptop/USB latency wi ll be very challenging, not to mansion the amount of data/traffic involved. That's why i think you need some local processing hardware.

My whole problem started with the local processing hardware, Im just a begi nner and just know about arduino and raspberry pi. I took a quick look at t heir specifications and decided to do it with the RPI.

It has no analog inputs so an ADC must be used, i didnt know about the simu ltaneous sampling ADCs so i thought of using 6 separate ADCs but due to the SPI latency at the RPI my project wont work in real-time applications.

The LTC1408-12 has six channels, 12 bits resolution, a sampling rate up to

100ksps and i can get a lower sampling rate by using the CONV and SCK pins.

This ADC solves my problem related to Analog-Digital conversion, the rest i s choosing the right chip to do the processing, i have not checked any DSP chip to do that and i thought of using the PC(thats why i asked about that) .

I will be looking for the right DSP chip to do the processing and control t wo servo motors without any issues but untill that i will try to work it wi th the PC.

ase transform) on those signals gathered by the mics in order to obtain t he time delay between each pair of mics and find the direction of sound arr ival in 3D and steer a camera to that direction.

tend an angle is ...

1.7 inches of delay. you may need to place your mikes at 'wide' locations, because close up more accurate than if the subject is 15 feet away

identify the interesting time frame, you probably need higher resolution s amplings. Assuming that you also have some servo controlling of the camera , you have a very tight control loop. Doing it with PC/laptop/USB latency will be very challenging, not to mansion the amount of data/traffic involve d. That's why i think you need some local processing hardware.

ginner and just know about arduino and raspberry pi. I took a quick look at their specifications and decided to do it with the RPI.

Arduino won't work anyway. RPI might work if you use parallel buses.

multaneous sampling ADCs so i thought of using 6 separate ADCs but due to t he SPI latency at the RPI my project wont work in real-time applications.

If you think SPI latency is bad, don't even look at USB latency.

If you use PC to do the processing, you have to send all the raw data via U SB.

On Wednesday, 10 September 2014 20:40:34 UTC+3, snipped-for-privacy@gmail.com wrote :

phase transform) on those signals gathered by the mics in order to obtain the time delay between each pair of mics and find the direction of sound a rrival in 3D and steer a camera to that direction.

.

ubtend an angle is ...

f 1.7 inches of delay. you may need to place your mikes at 'wide' location s, because close up more accurate than if the subject is 15 feet away

ou identify the interesting time frame, you probably need higher resolution samplings. Assuming that you also have some servo controlling of the came ra, you have a very tight control loop. Doing it with PC/laptop/USB latenc y will be very challenging, not to mansion the amount of data/traffic invol ved. That's why i think you need some local processing hardware.

beginner and just know about arduino and raspberry pi. I took a quick look at their specifications and decided to do it with the RPI.

simultaneous sampling ADCs so i thought of using 6 separate ADCs but due to the SPI latency at the RPI my project wont work in real-time applications.

USB.

then based on what i understood form your post, using an ADC with parallel buses or converting the serial input into parallel well solve the issue?

h phase transform) on those signals gathered by the mics in order to obta in the time delay between each pair of mics and find the direction of sound arrival in 3D and steer a camera to that direction.

subtend an angle is ...

of 1.7 inches of delay. you may need to place your mikes at 'wide' locati ons, because close up more accurate than if the subject is 15 feet away

you identify the interesting time frame, you probably need higher resoluti on samplings. Assuming that you also have some servo controlling of the ca mera, you have a very tight control loop. Doing it with PC/laptop/USB late ncy will be very challenging, not to mansion the amount of data/traffic inv olved. That's why i think you need some local processing hardware.

a beginner and just know about arduino and raspberry pi. I took a quick loo k at their specifications and decided to do it with the RPI.

e simultaneous sampling ADCs so i thought of using 6 separate ADCs but due to the SPI latency at the RPI my project wont work in real-time application s.

ia USB.

l buses or converting the serial input into parallel well solve the issue?

If you have serial input, you have a bottle neck there. RPi also introduce latency if it's running something like linux from SD card.

Putting the PIC on RPi might work, if you also let the PIC do most of the r eal time work.

Most people learn failures in this order:

1. Won't work with PC/USB
2. Won't work with Arduino
3. Won't work with RPi
4. Might work with PICMZ on RPi

So, it's OK for you to first learn how to fail.

Which brings to mind a gag project I've had ruminating on for some time...

I had an Indian (Native American) ceremonial mask hanging on the wall of my office... rather scary looking thing with holes at eye location.

I'd like to add eyeballs and a motion detector such that the eyes would "follow" you as you walk by ;-)

Any simple ideas? ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    | 
| San Tan Valley, AZ 85142     Skype: skypeanalog  |             | 
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  | 
| E-mail Icon at http://www.analog-innovations.com |    1962     | 
              
I love to cook with wine.     Sometimes I even put it in the food.

On a sunny day (Wed, 10 Sep 2014 11:26:04 -0700) it happened Jim Thompson wrote in :

In Linux 'xeyes' follows your mouse. You could stand behind the mask, come to think of it. :-)

phase transform) on those signals gathered by the mics in order to obtai n the time delay between each pair of mics and find the direction of sound arrival in 3D and steer a camera to that direction.

t.

subtend an angle is ...

of 1.7 inches of delay. you may need to place your mikes at 'wide' locatio ns, because close up more accurate than if the subject is 15 feet away

you identify the interesting time frame, you probably need higher resolutio n samplings. Assuming that you also have some servo controlling of the cam era, you have a very tight control loop. Doing it with PC/laptop/USB laten cy will be very challenging, not to mansion the amount of data/traffic invo lved. That's why i think you need some local processing hardware.

beginner and just know about arduino and raspberry pi. I took a quick look at their specifications and decided to do it with the RPI.

simultaneous sampling ADCs so i thought of using 6 separate ADCs but due t o the SPI latency at the RPI my project wont work in real-time applications .

a USB.

.

my office... rather scary looking thing with holes at eye location.

follow" you as you walk by ;-)

Not simple, but doable. I would use a camera to detector moton, and drive a simple motor.

Actually, this is similar to my idea of driving hand free. I would just mo unt the camera facing the driver. Blink your right eye if you want to turn right and left eye if you want to turn left. If you have eye allege, stay home!

On a sunny day (Wed, 10 Sep 2014 18:33:31 GMT) it happened Jan Panteltje wrote in :

Like this for thsoe who do not have Linux:

phase transform) on those signals gathered by the mics in order to obtai n the time delay between each pair of mics and find the direction of sound arrival in 3D and steer a camera to that direction.

t.

subtend an angle is ...

of 1.7 inches of delay. you may need to place your mikes at 'wide' locatio ns, because close up more accurate than if the subject is 15 feet away

you identify the interesting time frame, you probably need higher resolutio n samplings. Assuming that you also have some servo controlling of the cam era, you have a very tight control loop. Doing it with PC/laptop/USB laten cy will be very challenging, not to mansion the amount of data/traffic invo lved. That's why i think you need some local processing hardware.

beginner and just know about arduino and raspberry pi. I took a quick look at their specifications and decided to do it with the RPI.

simultaneous sampling ADCs so i thought of using 6 separate ADCs but due t o the SPI latency at the RPI my project wont work in real-time applications .

a USB.

I guess that this project would help you, instead of moving the camera you can use the motors to control eyeballs.

i/?ALLSTEPS

The difference between this project and mine is that he used face detection to do localization and tracking, mine requires time delays between microph one pairs with known positions localize and track the speaker.

OH, wait! If you only get the connection through a USB socket, the rest of your project could still fail: you need to know WHEN each sample was taken, so there's a small matter of getting a time-stamp with each sample. At least you know (because of the choice of converter) all inputs were latched simultaneously, you just don't know if the USB bus got tied up with other signals and skipped a beat or three.

I'm sure there's a good way to know that the six values you download are all at the same time (and you aren't getting three from today and three from yesterday, when the ADC is still mid-conversion).

I think the issues of using an SPI interface are overblown. SPI is plenty fast enough that you can get the data into a CPU in a short time relative to the 120 ms corresponding to an 8 kHz sample rate. I believe that is what you said you wanted to use. Even at 48 kHz sample rate you have over 20 us which is time to transfer some 200 bits on many SPI ports. The question is how fast SPI will work on the rPi and how long it will take to get the data from the SPI interface into the software.

I agree with others that you will be better off with a small MCU to do the data collection (possibly). But if you are doing the heavy lifting (math) in the rPi, you still need an efficient interface between the MCU and the rPi. There are plenty of MCUs that can do the math work such as an ARM Cortex M4 with floating point. You can get these with plenty of RAM/Flash. Eval boards are available inexpensively. Usually they have ADC/DAC on chip, so they won't add external chips to the low cost eval boards. You can either work with the internal ADC, likely it is multiplexed to a number of I/O pins, or you can add the ADC of your choice. You can sometimes find eval boards for ADC chips which could be wired to an eval board for your MCU. No real hardware work.

Maybe take a look at the TI ARM devices. I think they are called TIVA (used to be Stellaris). There is a version of Forth available for them called Mecrisp. Forth is very interactive and real time, great for programming the bare metal.

Sounds like a decent choice. What is the interface to the host?

You still need to deal with the hardware issues. Do they have an eval board?

A DSP chip might be a good choice, but are you ready to program it? The ARM Cortex M4 has DSP like capabilities with near single cycle MAC functionality. But there are some low cost DSP chips as well. TI is a great DSP supplier too.

--

Rick

--
125 **micro** seconds.

Do you really need six microphones ?

Have you checked Michael Gerzon, Ambisonics and "soundfield microphone". This should give sufficient information about the sound location in a 3 D space with four microphones (A and B formats).

Regarding using multiple (USB) soundcards, as some have suggested, would be out of the question, since the sampling frequency and sampling timing can't be controlled between units.

If you are going to mechanically control a camera, a single 4 or 6 channel ADC connected with USB to a PC would be quite adequate, since the camera movement is much too slower than the USB latencies.

Interesting.

Doing a Project you should put some 'numbers' to the design so you know when you're done, determine success.

A number like this, can you stand 50mS latency? yes/no?

If a person is moving at a walking speed of four miles per hour, that's 70 inches per second. [hmmmm, seems a bit high, because the fastest speed I could swipe a mag card through a reader was 40 ips] Anyway, let's use that number. With 50mS of latency, you get a 'walker' moving a distance of 3.5 inches. ok, might lose him, without some really clever software. But the point is GET some numbers, GET some expected performance numbers!

For what it's worth, I made a real-time system using a soundcard running on a WinXP OS [spit, spit, curse begone!] with a super slow 600MHz clock. The two channels of data came in at 24 bits and 192kS/s each followed by DSP, curve fittings, multiple FFT's, pattern recognition, image splicing, GUI/displays, all real-time with a latency of 50mS. Ignoring the 24 bits, that's 384kS/s. divide by 8 channels still yields a sample rate of 48kS/s, maybe that's where that number comes from. Anyway, audio work you'll have difficulty getting latency below 50mS. Unless you make your own ADC section. Let's see, 8kS/s with a latency of 20mS, you get to compare 160 samples. Wow! that's not a lot. Bet noise eats you alive on the position accuracy.

Interesting project. potential application in shooting down drones, eh? ;)

For shame! hijacking this man's thread! oh well the gag sounds too good NOT to contribute something. Heat seeking? Then there are those leftover ultrasonic focusing units from Polaroid's cameras where a widely separated pair [1 meter] could be adapted to yield the position. You could sell this in Oct on eBay!

A friend of mine owns a robotic company [he wrote the OS for a well-known humanoid robot] He invented 'silent' robotic motion. Has none of that ZZHH, ZZHH associated with stepper motors. He powered a robotic arm hanging on a coat rack in his office and when someone gets close to the 'arm' it swings out and grabs at him, silently. Now THAT's spooky!

oduce latency if it's running something like linux from SD card.

he real time work.

hen you're done, determine success.

0 inches per second. [hmmmm, seems a bit high, because the fastest speed I could swipe a mag card through a reader was 40 ips] Anyway, let's use that number. With 50mS of latency, you get a 'walker' moving a distance of 3.5 i nches. ok, might lose him, without some really clever software. But the p oint is GET some numbers, GET some expected performance numbers!

Most of the range finders/motion trackers are ultrasonic. I think the OP n eed high end audio (48KHz+) if not ultrasonic.

Hmmm..does that include launching sound AT the speaker to find the speaker? With a little bit of game playing, you easily double the frequency going through that audio card to go up passed 200kHz, not ultrasonic but pretty decent spatial resolution.

With ultrasonic microphones may not need to launch energy. The body's skin squeaks at those frequencies and clothing rustles gang busters, too. Just you get a lot of attenuation from there to the mikes.

Got the paper thanks! Reading that paper makes for an interesting thought process.

I can't believe 8kS/s is adequate for spatial triangulation, but I do not have experience doing such. I have found that excessive bandwidth usually helps, though. For example going from 8kS/s to 48kS/s increases the information 6 fold. And summing it all back down to lower rates somehow has to improve S/N.

*if* you use time correlation, shifting samples along the time axis to find a match produces an output signal that should spike when 'lined up' However, phase shifts, non-linearities, and ?? will screw this up. *if* you take the FFT, you have half the number of samples to work with [nice advantage to complexity of calculations] AND you get to isolate the effects of reverberation which cause tonal enhancements and weird phase shifts in those resonant regions that will screw EVERYTHING up.

hmmmm what to do? what to do?

you could take the FFT, 'recognize the resonant regions, throw any resonant region data out and work in and around those pesky frequency bins, accepting only information from 'clear' frequency bins. THEN you should get better performance thnn the authors of that paper.

Again, interesting project. Can't wait until you get through the hardware construction phase to really start learning from this.

PS: there's a real simple way to get inputs muxed into a two input soundcard by using the output channels to drive the mux. Use the USB port for power and the soundcard as the ADC and you get everything synchronized with very little hardware added.

The interface is a 3-wire SPI serial interface (If i got your question correctly).

According to Digikey those are the evaluation boards from Linear Tech:

and it seems that they wont work with my ADC(LTC1408-12).

I will search for an evaluation board, but it must be compatible with the LTC1408-12. Im sure it wont be a problem, if so then i will consider using a DSP chip.

Regards,