Real Life Beamforming with substandard arrays. Need help forming some sort of solution.

On Jun 26, 4:28 pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> Phil Winder wrote:
>
> [...]
>
> > @Rune: Ah yeah, never thought of it that way. Well you could argue
> > that the spreading in the pulse is in some part due to multipath.
> > That will only affect the temporal resoultion, so I not too fussed
> > about that yet.  I want to get some sort of directivity first.   And
> > yes, I will try and interpolate and see if that helps.
>
> Interpolation after the acquisition won't yield that much. Since it
> seems you are bent on using a small uC you could try this:
>
> a. Fire -> Acquire at 200ksps.
> b. Fire one MCLK cycle delayed -> Acquire at 200ksps.
> c. Fire two MCLK cycles delayed -> Acquire at 200ksps.
> d. ...
> .
> .
> .
>
> Stop after you are one MCLK cycle away from a 360 turn on your 200kHz
> ADC clock. Now stitch together all the information gathered. Now if your
> uC begins to choke under all that data you could loosen the spec a bit,
> maybe step several MCLK cycles each time but you need to get into the
> vicinity of at least 1MSPS.
>
> This is pretty much how digital scopes work in equivalent time sampling
> mode, where their ADC isn't fast enough for the signal. It requires that
> the signal doesn't move, or in your case that the targets don't move too
> much.
>
> [...]
>
> --
> Regards, Joerg
>
> http://www.analogconsultants.com/
>
> "gmail" domain blocked because of excessive spam.
> Use another domain or send PM.

Interesting, but wouldn't you have to capture 360*4=1440 signals? say
1000 samples per signal, that's a lot of data.  It would guarantee
accuracy though.  Also, I think my microcontroller only has one ADC
clock source, so I wouldnt be able to independently start different
channels.  (will check though) All are linked to the same 200kHz
clock.  Also, I dont think I can individually sample inputs manually
since the SAR ADC needs a sampling time.

Good idea nevertheless...

I dont know about the interpolation, since the received signals are
pretty much sine waves, I'm quite confident that some sort of spline
or even polynomial interpolation will do pretty well with the signal.
The only problem that I can foresee is that my signals are not
synchronised.  At the moment I can only sample 1 channel at a time due
to the rubbish on board ADC, but I have just got a new one where you
can sample synchronously, so hopefully after Ive rewritten the code
for that (argh) it should be ok.

I'm bent on using microcontrollers to capture the data because they
are cheap and quite easy to use.  And I have quite a bit of experience
with them.  What would you suggest I use? Thinking low cost?

Cheers,
Phil

Phil Winder wrote:
> On Jun 26, 4:28 pm, Joerg <notthisjoerg...@removethispacbell.net>
> wrote:
>> Phil Winder wrote:
>>
>> [...]
>>
>>> @Rune: Ah yeah, never thought of it that way. Well you could argue
>>> that the spreading in the pulse is in some part due to multipath.
>>> That will only affect the temporal resoultion, so I not too fussed
>>> about that yet.  I want to get some sort of directivity first.   And
>>> yes, I will try and interpolate and see if that helps.
>> Interpolation after the acquisition won't yield that much. Since it
>> seems you are bent on using a small uC you could try this:
>>
>> a. Fire -> Acquire at 200ksps.
>> b. Fire one MCLK cycle delayed -> Acquire at 200ksps.
>> c. Fire two MCLK cycles delayed -> Acquire at 200ksps.
>> d. ...
>> .
>> .
>> .
>>
>> Stop after you are one MCLK cycle away from a 360 turn on your 200kHz
>> ADC clock. Now stitch together all the information gathered. Now if your
>> uC begins to choke under all that data you could loosen the spec a bit,
>> maybe step several MCLK cycles each time but you need to get into the
>> vicinity of at least 1MSPS.
>>
>> This is pretty much how digital scopes work in equivalent time sampling
>> mode, where their ADC isn't fast enough for the signal. It requires that
>> the signal doesn't move, or in your case that the targets don't move too
>> much.
>>
>> [...]
>>
>> --
>> Regards, Joerg
>>
>> http://www.analogconsultants.com/
>>
>> "gmail" domain blocked because of excessive spam.
>> Use another domain or send PM.
> 
> Interesting, but wouldn't you have to capture 360*4=1440 signals? say
> 1000 samples per signal, that's a lot of data.  It would guarantee
> accuracy though.  Also, I think my microcontroller only has one ADC
> clock source, so I wouldnt be able to independently start different
> channels.  (will check though) All are linked to the same 200kHz
> clock.  Also, I dont think I can individually sample inputs manually
> since the SAR ADC needs a sampling time.
> 

If your targets don't move much you could process in chunks. For 
example, only take the first 100 samples, do all the clock stagger runs, 
calculate the result, store that, then move on to sample 101 through 
200, and so on. It'll slow down the whole process but what can you do 
with such limited resources? Also you'd have to somewhat gracefully 
stitch together at the range ends, maybe let them overlap a few samples.

WRT the clock source I didn't mean switching the ADC clock but scooting 
the transmit pulses themselves. There you should have a much more direct 
control. For example you could run a timer and update the CCR after 
every shot. Of course, us HW guys always seem to run out of timers no 
matter how many there are on the uC ;-)


> Good idea nevertheless...
> 
> I dont know about the interpolation, since the received signals are
> pretty much sine waves, I'm quite confident that some sort of spline
> or even polynomial interpolation will do pretty well with the signal.
> The only problem that I can foresee is that my signals are not
> synchronised.  At the moment I can only sample 1 channel at a time due
> to the rubbish on board ADC, but I have just got a new one where you
> can sample synchronously, so hopefully after Ive rewritten the code
> for that (argh) it should be ok.
> 

Be careful. Multiple channels often come with speed penalties, IOW four 
channels can slash your sample rate to 1/4th.


> I'm bent on using microcontrollers to capture the data because they
> are cheap and quite easy to use.  And I have quite a bit of experience
> with them.  What would you suggest I use? Thinking low cost?
> 

Probably some kind of DSP would be better but it'll cost north of $5 in 
quantities. ARM might be another option since they often offer a lot 
more horsepower and RAM.

ADCs on uC are notoriously noisy so I'd consider an off-chip converter 
if the BOM budget allows it.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

On Jun 26, 9:43 pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> Phil Winder wrote:
> > On Jun 26, 4:28 pm, Joerg <notthisjoerg...@removethispacbell.net>
> > wrote:
> >> Phil Winder wrote:
>
> >> [...]
>
> >>> @Rune: Ah yeah, never thought of it that way. Well you could argue
> >>> that the spreading in the pulse is in some part due to multipath.
> >>> That will only affect the temporal resoultion, so I not too fussed
> >>> about that yet.  I want to get some sort of directivity first.   And
> >>> yes, I will try and interpolate and see if that helps.
> >> Interpolation after the acquisition won't yield that much. Since it
> >> seems you are bent on using a small uC you could try this:
>
> >> a. Fire -> Acquire at 200ksps.
> >> b. Fire one MCLK cycle delayed -> Acquire at 200ksps.
> >> c. Fire two MCLK cycles delayed -> Acquire at 200ksps.
> >> d. ...
> >> .
> >> .
> >> .
>
> >> Stop after you are one MCLK cycle away from a 360 turn on your 200kHz
> >> ADC clock. Now stitch together all the information gathered. Now if your
> >> uC begins to choke under all that data you could loosen the spec a bit,
> >> maybe step several MCLK cycles each time but you need to get into the
> >> vicinity of at least 1MSPS.
>
> >> This is pretty much how digital scopes work in equivalent time sampling
> >> mode, where their ADC isn't fast enough for the signal. It requires that
> >> the signal doesn't move, or in your case that the targets don't move too
> >> much.
>
> >> [...]
>
> >> --
> >> Regards, Joerg
>
> >>http://www.analogconsultants.com/
>
> >> "gmail" domain blocked because of excessive spam.
> >> Use another domain or send PM.
>
> > Interesting, but wouldn't you have to capture 360*4=1440 signals? say
> > 1000 samples per signal, that's a lot of data.  It would guarantee
> > accuracy though.  Also, I think my microcontroller only has one ADC
> > clock source, so I wouldnt be able to independently start different
> > channels.  (will check though) All are linked to the same 200kHz
> > clock.  Also, I dont think I can individually sample inputs manually
> > since the SAR ADC needs a sampling time.
>
> If your targets don't move much you could process in chunks. For
> example, only take the first 100 samples, do all the clock stagger runs,
> calculate the result, store that, then move on to sample 101 through
> 200, and so on. It'll slow down the whole process but what can you do
> with such limited resources? Also you'd have to somewhat gracefully
> stitch together at the range ends, maybe let them overlap a few samples.
>
> WRT the clock source I didn't mean switching the ADC clock but scooting
> the transmit pulses themselves. There you should have a much more direct
> control. For example you could run a timer and update the CCR after
> every shot. Of course, us HW guys always seem to run out of timers no
> matter how many there are on the uC ;-)
>
> > Good idea nevertheless...
>
> > I dont know about the interpolation, since the received signals are
> > pretty much sine waves, I'm quite confident that some sort of spline
> > or even polynomial interpolation will do pretty well with the signal.
> > The only problem that I can foresee is that my signals are not
> > synchronised.  At the moment I can only sample 1 channel at a time due
> > to the rubbish on board ADC, but I have just got a new one where you
> > can sample synchronously, so hopefully after Ive rewritten the code
> > for that (argh) it should be ok.
>
> Be careful. Multiple channels often come with speed penalties, IOW four
> channels can slash your sample rate to 1/4th.
>
> > I'm bent on using microcontrollers to capture the data because they
> > are cheap and quite easy to use.  And I have quite a bit of experience
> > with them.  What would you suggest I use? Thinking low cost?
>
> Probably some kind of DSP would be better but it'll cost north of $5 in
> quantities. ARM might be another option since they often offer a lot
> more horsepower and RAM.
>
> ADCs on uC are notoriously noisy so I'd consider an off-chip converter
> if the BOM budget allows it.
>
> --
> Regards, Joerg
>
> http://www.analogconsultants.com/
>
> "gmail" domain blocked because of excessive spam.
> Use another domain or send PM.

Yes I could do it with the tranmits, since they do run on seperate
clocks.  But I haven't started playing with the transmit beamforming
yet, although I would expect it to be a bit easier.

The 1/4th problem is exactly why I have swapped chips!  I'm about to
use the dsPIC33FJ64.  Sequential Sampling, more RAM etc.
Yes to the noise too, so I will see how it goes.  I can cope with the
noise for now.  Just decreases range/resolution etc.  Were not exactly
mission critical here!

Just as another note, for now I'm actually doing all the receive
beamforming on an external PC, not the microcontroller.  I just sample
and store the raw data then transmit to the PC.  So the only problems
can occur in the capture itself.  The amount of data being sampled is
currently dependent on RAM, but I am going to try and save it to an
EEPROM rather than the RAM.  Lots more space.

Many thanks,

Phil

Phil Winder wrote:

[...]

> 
> Yes I could do it with the tranmits, since they do run on seperate
> clocks.  But I haven't started playing with the transmit beamforming
> yet, although I would expect it to be a bit easier.
> 

It has nothing to do with transmit beamforming, although at some point 
you'll have to tackle that topic as well. I just meant to scoot the 
transmit pulse a little for each run so your ADC still "thinks" it got 
sample #3 at 15usec instead of at 15.5usec after the transmit pulse. IOW 
sample #3 would come at 15usec, then 15.5usec, then 16usec and so on 
until you are at 19.5usec.


> The 1/4th problem is exactly why I have swapped chips!  I'm about to
> use the dsPIC33FJ64.  Sequential Sampling, more RAM etc.
> Yes to the noise too, so I will see how it goes.  I can cope with the
> noise for now.  Just decreases range/resolution etc.  Were not exactly
> mission critical here!
> 
> Just as another note, for now I'm actually doing all the receive
> beamforming on an external PC, not the microcontroller.  I just sample
> and store the raw data then transmit to the PC.  So the only problems
> can occur in the capture itself.  The amount of data being sampled is
> currently dependent on RAM, but I am going to try and save it to an
> EEPROM rather than the RAM.  Lots more space.
> 

Doing the first tests on a PC is the smart thing to do, saves lots of 
time. Careful with flash since that has a finite number of write cycles 
and the write process isn't very fast. Plus often you have to write it 
in banks.

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

"Phil Winder" <philipwinder@googlemail.com> wrote in message 
news:21ae1e6d-1e0c-42e1-a6d3-32a7c510e80c@e39g2000hsf.googlegroups.com...

Phil,

It's not quite clear to me what you're trying to accomplish by steering the 
receive beam.  It would be nice to know.

As has been pointed out, 1 wavelength spacing is problematic to a degree 
because the beam pattern for omni elements would repeat every 90 degrees. 
If the elements aren't omni then the situation is somewhat better.

Staggering the elements puts two elements behind the others.  That's a 
built-in delay.  How much is it?  It means the broadside beam may not be the 
main lobe unless the staggered distance is also 1 wavelength or unless 
there's some delay associated with summing the forward elements.  It's 
surely a more complicated arrangement than a line array.

Have you computed a theoretical beam pattern?  If you assume omni elements 
it's easiest to do and then you can either calculate or just "adjust" the 
result for the element beam patterns.

Fred

On Jun 27, 3:05 am, "Fred Marshall" <fmarshallx@remove_the_x.acm.org>
wrote:
> "Phil Winder" <philipwin...@googlemail.com> wrote in message
>
> news:21ae1e6d-1e0c-42e1-a6d3-32a7c510e80c@e39g2000hsf.googlegroups.com...
>
> Phil,
>
> It's not quite clear to me what you're trying to accomplish by steering the
> receive beam.  It would be nice to know.
>
> As has been pointed out, 1 wavelength spacing is problematic to a degree
> because the beam pattern for omni elements would repeat every 90 degrees.
> If the elements aren't omni then the situation is somewhat better.
>
> Staggering the elements puts two elements behind the others.  That's a
> built-in delay.  How much is it?  It means the broadside beam may not be the
> main lobe unless the staggered distance is also 1 wavelength or unless
> there's some delay associated with summing the forward elements.  It's
> surely a more complicated arrangement than a line array.
>
> Have you computed a theoretical beam pattern?  If you assume omni elements
> it's easiest to do and then you can either calculate or just "adjust" the
> result for the element beam patterns.
>
> Fred

@ Joerg: Ahh, got you.  You mean do more than one transmit and receive
cycle, but add a slight delay to the receive on the second and
subsequent receives. Thanks.

@ Fred: I just fancied having a go thats all!  I did think about
mounting a single rx/tx onto a servo/stepper motor, but I decided that
it wasn't very elegant.  Plus I was interested in beamforming, so I
gave it a shot.  Eventually I would like to mount it onto a robot
possibly, or maybe just use it as a real time show-off piece!

The elements are not behind each other, they are stacked on top of
each other.  If looking directly at the array, the x spacing is 3 x 1
wavelength and the y spacing is 1 x 1 wavelength.  So the patter looks
like the pattern on a football (if they were circular pieces of
leather!). Or like a parallelogram filled with 4 circular transducers.
Ooh, forgot I had some images on the web! ( http://www.philwinder.com/uploads/2008/04/img_0001.JPG
or http://www.philwinder.com/wordpress/2008/04/25/phased-array-pcb-v01-finished/
)

I have calculated the beam pattern for a linear array, but not for
this stacked arrangement.  I probably should, but intuitively I
thought that the x spacing was conserved, so it shouldn't be a problem
unless the target is much lower or higher than the transmitters.  What
I should do really is scan not only the 4 X transducers, but the 2 Y
transducers too.  But for now I am making sure that they are level.

Thanks,
Phil

Phil Winder wrote:
> On Jun 27, 3:05 am, "Fred Marshall" <fmarshallx@remove_the_x.acm.org>
> wrote:
>> "Phil Winder" <philipwin...@googlemail.com> wrote in message
>>
>> news:21ae1e6d-1e0c-42e1-a6d3-32a7c510e80c@e39g2000hsf.googlegroups.com...
>>
>> Phil,
>>
>> It's not quite clear to me what you're trying to accomplish by steering the
>> receive beam.  It would be nice to know.
>>
>> As has been pointed out, 1 wavelength spacing is problematic to a degree
>> because the beam pattern for omni elements would repeat every 90 degrees.
>> If the elements aren't omni then the situation is somewhat better.
>>
>> Staggering the elements puts two elements behind the others.  That's a
>> built-in delay.  How much is it?  It means the broadside beam may not be the
>> main lobe unless the staggered distance is also 1 wavelength or unless
>> there's some delay associated with summing the forward elements.  It's
>> surely a more complicated arrangement than a line array.
>>
>> Have you computed a theoretical beam pattern?  If you assume omni elements
>> it's easiest to do and then you can either calculate or just "adjust" the
>> result for the element beam patterns.
>>
>> Fred
> 
> @ Joerg: Ahh, got you.  You mean do more than one transmit and receive
> cycle, but add a slight delay to the receive on the second and
> subsequent receives. Thanks.
> 

Yep, and adding delay to the transmit pulses is often easier than 
sloshing the ADC clock around. Especially if it ain't a flash converter.


> @ Fred: I just fancied having a go thats all!  I did think about
> mounting a single rx/tx onto a servo/stepper motor, but I decided that
> it wasn't very elegant.  Plus I was interested in beamforming, so I
> gave it a shot.  Eventually I would like to mount it onto a robot
> possibly, or maybe just use it as a real time show-off piece!
> 
> The elements are not behind each other, they are stacked on top of
> each other.  If looking directly at the array, the x spacing is 3 x 1
> wavelength and the y spacing is 1 x 1 wavelength.  So the patter looks
> like the pattern on a football (if they were circular pieces of
> leather!). Or like a parallelogram filled with 4 circular transducers.
> Ooh, forgot I had some images on the web! ( http://www.philwinder.com/uploads/2008/04/img_0001.JPG
> or http://www.philwinder.com/wordpress/2008/04/25/phased-array-pcb-v01-finished/
> )
> 

That's too much spacing for good beamforming.


> I have calculated the beam pattern for a linear array, but not for
> this stacked arrangement.  I probably should, but intuitively I
> thought that the x spacing was conserved, so it shouldn't be a problem
> unless the target is much lower or higher than the transmitters.  What
> I should do really is scan not only the 4 X transducers, but the 2 Y
> transducers too.  But for now I am making sure that they are level.
> 

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

On Jun 27, 6:40 pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> Phil Winder wrote:
> > On Jun 27, 3:05 am, "Fred Marshall" <fmarshallx@remove_the_x.acm.org>
> > wrote:
> >> "Phil Winder" <philipwin...@googlemail.com> wrote in message
>
> >>news:21ae1e6d-1e0c-42e1-a6d3-32a7c510e80c@e39g2000hsf.googlegroups.com...
>
> >> Phil,
>
> >> It's not quite clear to me what you're trying to accomplish by steering the
> >> receive beam.  It would be nice to know.
>
> >> As has been pointed out, 1 wavelength spacing is problematic to a degree
> >> because the beam pattern for omni elements would repeat every 90 degrees.
> >> If the elements aren't omni then the situation is somewhat better.
>
> >> Staggering the elements puts two elements behind the others.  That's a
> >> built-in delay.  How much is it?  It means the broadside beam may not be the
> >> main lobe unless the staggered distance is also 1 wavelength or unless
> >> there's some delay associated with summing the forward elements.  It's
> >> surely a more complicated arrangement than a line array.
>
> >> Have you computed a theoretical beam pattern?  If you assume omni elements
> >> it's easiest to do and then you can either calculate or just "adjust" the
> >> result for the element beam patterns.
>
> >> Fred
>
> > @ Joerg: Ahh, got you.  You mean do more than one transmit and receive
> > cycle, but add a slight delay to the receive on the second and
> > subsequent receives. Thanks.
>
> Yep, and adding delay to the transmit pulses is often easier than
> sloshing the ADC clock around. Especially if it ain't a flash converter.
>
> > @ Fred: I just fancied having a go thats all!  I did think about
> > mounting a single rx/tx onto a servo/stepper motor, but I decided that
> > it wasn't very elegant.  Plus I was interested in beamforming, so I
> > gave it a shot.  Eventually I would like to mount it onto a robot
> > possibly, or maybe just use it as a real time show-off piece!
>
> > The elements are not behind each other, they are stacked on top of
> > each other.  If looking directly at the array, the x spacing is 3 x 1
> > wavelength and the y spacing is 1 x 1 wavelength.  So the patter looks
> > like the pattern on a football (if they were circular pieces of
> > leather!). Or like a parallelogram filled with 4 circular transducers.
> > Ooh, forgot I had some images on the web! (http://www.philwinder.com/uploads/2008/04/img_0001.JPG
> > orhttp://www.philwinder.com/wordpress/2008/04/25/phased-array-pcb-v01-f...
> > )
>
> That's too much spacing for good beamforming.
>
> > I have calculated the beam pattern for a linear array, but not for
> > this stacked arrangement.  I probably should, but intuitively I
> > thought that the x spacing was conserved, so it shouldn't be a problem
> > unless the target is much lower or higher than the transmitters.  What
> > I should do really is scan not only the 4 X transducers, but the 2 Y
> > transducers too.  But for now I am making sure that they are level.
>
> --
> Regards, Joerg
>
> http://www.analogconsultants.com/
>
> "gmail" domain blocked because of excessive spam.
> Use another domain or send PM.

Hi all,
I just though I would update you on what I have found sine you all
took the time to help me.
I have implemented a new microcontroller that has simultaneous
sampling and a slightly higher sampling rate.  I could then
interpolate the data with pretty good results using a simple padding +
band pass filtering technique.  The higher the SNR the better it
worked.
However, I have hit a great big wall.  It all boils down to the fact
that I have used 2 rows of transducers to make the spacing 1
wavelength.

For the following results, Consider the situation where x is the
horizontal plane, y is the vertical plane and z is the distance
between the source and the target.  If the target is slightly elevated
in the y plane, the top and bottommost transducers would receive an
echo at different times.  Furthermore, due to multipath dispersion I
am also receiving further echoes from different y directions.  So to
counteract this, I would have to scan not only in the x plane, but in
the y plane too, and this was accomplished by summing all of the
results in the y direction to produce a plot of the targets in the x
plane.  However, by delaying the signals in the y plane, the x plane
in some situations became erroneous.  It looks like I am getting some
sort of aliasing in the x plane.  I think that this is because of
instead of having a beam pattern from 4 transducers, I am getting 2 x
2 transducer patterns, so not only do I now have a very very wide beam
width, I will have some nasty sidelobes too (since if you just
consider the 2 transducers, the spacing is 2 x wavelength.)

On the up side, the hardware side of it works great!

So all around, this was pretty much a disaster, and I am not looking
forward to remaking all of the hardware.  So for beta 2 I will need:
o to source some smaller transducers so that I can get 1/2 x
wavelength spacing in a linear fashion. Possibly go higher in
frequency to get a better z resolution.
o use a dedicated ADC with 8 transducers, rather than 4.  Get
something with a faster sampling rate too.
o remake the hardware :(

The hardest thing I see is sourcing the peizoceramics from somewhere.
Does anyone know of where I can get any cheaply online?  Self enclosed
transducers would be ideal, but I would be willing to mess with the
naked ceramics myself if I had too.

Thanks,
Phil Winder

Phil Winder wrote:

[...]

> Hi all,
> I just though I would update you on what I have found sine you all
> took the time to help me.
> I have implemented a new microcontroller that has simultaneous
> sampling and a slightly higher sampling rate.  I could then
> interpolate the data with pretty good results using a simple padding +
> band pass filtering technique.  The higher the SNR the better it
> worked.
> However, I have hit a great big wall.  It all boils down to the fact
> that I have used 2 rows of transducers to make the spacing 1
> wavelength.
> 

If it's any consolation, we have all hit that wall. One wavelength is a 
bit coarse.


> For the following results, Consider the situation where x is the
> horizontal plane, y is the vertical plane and z is the distance
> between the source and the target.  If the target is slightly elevated
> in the y plane, the top and bottommost transducers would receive an
> echo at different times.  Furthermore, due to multipath dispersion I
> am also receiving further echoes from different y directions.  So to
> counteract this, I would have to scan not only in the x plane, but in
> the y plane too, and this was accomplished by summing all of the
> results in the y direction to produce a plot of the targets in the x
> plane.  However, by delaying the signals in the y plane, the x plane
> in some situations became erroneous.  It looks like I am getting some
> sort of aliasing in the x plane.  I think that this is because of
> instead of having a beam pattern from 4 transducers, I am getting 2 x
> 2 transducer patterns, so not only do I now have a very very wide beam
> width, I will have some nasty sidelobes too (since if you just
> consider the 2 transducers, the spacing is 2 x wavelength.)
> 
> On the up side, the hardware side of it works great!
> 

At least now you are getting a good feel on how much HW performance you 
need. Might want ot try a real (external) ADC at some point.


> So all around, this was pretty much a disaster, and I am not looking
> forward to remaking all of the hardware.  So for beta 2 I will need:
> o to source some smaller transducers so that I can get 1/2 x
> wavelength spacing in a linear fashion. Possibly go higher in
> frequency to get a better z resolution.
> o use a dedicated ADC with 8 transducers, rather than 4.  Get
> something with a faster sampling rate too.
> o remake the hardware :(
> 
> The hardest thing I see is sourcing the peizoceramics from somewhere.
> Does anyone know of where I can get any cheaply online?  Self enclosed
> transducers would be ideal, but I would be willing to mess with the
> naked ceramics myself if I had too.
> 

I know PZT vendors but our stuff is always full custom volume 
production. IOW they dice, mount, backfill to our specs. It's all in the 
MHz range and I am not too familiar with 40kHz stuff. If it is the usual 
thickness excitation you could buy a bunch of cheap transducers, disect 
them and ten dice them with a diamond blade. Be careful, this is 
dangerous. Maybe leave the dicing to professionals who operate older 
dicing saws for wafers. They'll balk at first, don't want to contaminate 
their machines, so this may require holding a wad of cash in front of 
them ;-)

If this is on a shoestring budget you might ask around in robotics 
forums, see if someone has done it before. They often try to obtain 
better directivity for navigational purposes. Just don't get any raw 
PZT5H if it's not polarized. Polarization requires a HV source.

Oh man, it's 4:00pm and we can't see the sun anymore. Only smoke. <cough>

-- 
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

On Jul 9, 11:55 pm, Joerg <notthisjoerg...@removethispacbell.net>
wrote:
> Phil Winder wrote:
>
> [...]
>
> > Hi all,
> > I just though I would update you on what I have found sine you all
> > took the time to help me.
> > I have implemented a new microcontroller that has simultaneous
> > sampling and a slightly higher sampling rate.  I could then
> > interpolate the data with pretty good results using a simple padding +
> > band pass filtering technique.  The higher the SNR the better it
> > worked.
> > However, I have hit a great big wall.  It all boils down to the fact
> > that I have used 2 rows of transducers to make the spacing 1
> > wavelength.
>
> If it's any consolation, we have all hit that wall. One wavelength is a
> bit coarse.
>
>
>
> > For the following results, Consider the situation where x is the
> > horizontal plane, y is the vertical plane and z is the distance
> > between the source and the target.  If the target is slightly elevated
> > in the y plane, the top and bottommost transducers would receive an
> > echo at different times.  Furthermore, due to multipath dispersion I
> > am also receiving further echoes from different y directions.  So to
> > counteract this, I would have to scan not only in the x plane, but in
> > the y plane too, and this was accomplished by summing all of the
> > results in the y direction to produce a plot of the targets in the x
> > plane.  However, by delaying the signals in the y plane, the x plane
> > in some situations became erroneous.  It looks like I am getting some
> > sort of aliasing in the x plane.  I think that this is because of
> > instead of having a beam pattern from 4 transducers, I am getting 2 x
> > 2 transducer patterns, so not only do I now have a very very wide beam
> > width, I will have some nasty sidelobes too (since if you just
> > consider the 2 transducers, the spacing is 2 x wavelength.)
>
> > On the up side, the hardware side of it works great!
>
> At least now you are getting a good feel on how much HW performance you
> need. Might want ot try a real (external) ADC at some point.
>
> > So all around, this was pretty much a disaster, and I am not looking
> > forward to remaking all of the hardware.  So for beta 2 I will need:
> > o to source some smaller transducers so that I can get 1/2 x
> > wavelength spacing in a linear fashion. Possibly go higher in
> > frequency to get a better z resolution.
> > o use a dedicated ADC with 8 transducers, rather than 4.  Get
> > something with a faster sampling rate too.
> > o remake the hardware :(
>
> > The hardest thing I see is sourcing the peizoceramics from somewhere.
> > Does anyone know of where I can get any cheaply online?  Self enclosed
> > transducers would be ideal, but I would be willing to mess with the
> > naked ceramics myself if I had too.
>
> I know PZT vendors but our stuff is always full custom volume
> production. IOW they dice, mount, backfill to our specs. It's all in the
> MHz range and I am not too familiar with 40kHz stuff. If it is the usual
> thickness excitation you could buy a bunch of cheap transducers, disect
> them and ten dice them with a diamond blade. Be careful, this is
> dangerous. Maybe leave the dicing to professionals who operate older
> dicing saws for wafers. They'll balk at first, don't want to contaminate
> their machines, so this may require holding a wad of cash in front of
> them ;-)
>
> If this is on a shoestring budget you might ask around in robotics
> forums, see if someone has done it before. They often try to obtain
> better directivity for navigational purposes. Just don't get any raw
> PZT5H if it's not polarized. Polarization requires a HV source.
>
> Oh man, it's 4:00pm and we can't see the sun anymore. Only smoke. <cough>
>
> --
> Regards, Joerg
>
> http://www.analogconsultants.com/
>
> "gmail" domain blocked because of excessive spam.
> Use another domain or send PM.

Holy smokes!
Thanks for the thoughts, I would definitely not be able to do the
polarisation myself.  And like you said, these things are usually
bought it pretty big numbers....
But what I could do is try and dismantle one of these transducers I
have, maybe even cut a few down a little bit and see how they
perform.  Its not ideal, but it could work.

The only other option that i have been persuing is using 20kHz (or
even less).  That means 1 wavelength at 17mm and Ive found some
electret microphones transducers that measure 4mm wide so I would be
able to get half wavelength there.

By the way I presume that you are working underwater since at 1MHz
there's a wavelength of 0.3mm.  A tad small.

Best regards,
Phil