Just playing with an idea I had (my wife recently went to an ob-gyn, and I was watching the ultrasound equipment work...neat.)

So, I was thinking, are there any practical limitations to using the NerdKit (plus a few extra parts) to make a home ultrasound device? I think the difficult part would be finding the correct output frequency, and then reading returns on that frequency (and reading relative strength).

For example, if you take the speed of sound in water (which is basically what a person is) as 1482 m/s, and use the "depth" of a measurement as being 0.1 meters, then the highest sampling frequency is only 7.41 khz for a single pulse/return. Higher sampling on the listening end should be able to distinguish multiple returns from a single outbound pulse.

At 20Mhz, there could be about 2700 gradations of depth in the detection...or about 0.03 millimeters. Practically speaking, this kind of performance would be way too much to expect for a home-made project. But if we go about it the other way, say, asking for 1-millimeter resolution, then the following numbers work out:

@ 1mm resolution of depth, then the required frequency to get a 1-mm wavelength is only 482khz (might go with double that to make sampling easier, but still at 0.96 Mhz, well within the Atmega-168 specs, right?)

Sampling could be as high a rate as the circuitry would allow...as long as the "pings" are spaced enough to prevent detection overlap (the detection cycle processing a follow-on ping as the original ping).

The hard part would be the detector; putting out a 0.96 Mhz pulse from a NerdKit to a piezoelectric wouldn't be hard (though amping up the signal might be an issue). Ideally, the same type of crystal could be used to detect such a signal, though it probably wouldn't be sensitive enough by itself. Pre-amp of the return signal would probably be another design issue...

As far as displaying the data...probably nothing too fancy...even a fixed string of numbers giving relative strength of the return signal would work (leave it to the heavy programmers to turn it into a real picture.)

So, am I way off base with this idea? Does anyone have an idea of what kind of circuitry to make this work?

Actually, with one exception, you're on the right track. Your limitation is not speed-- the ATMEG168 MCU is plenty fast enough to do what you need. If you broadcast a sound, it comes from one point source, and spreads out, bouncing off of many things. That means you don't have just one (1) point of sounded intensity coming back at you-- you have many. Zillions in fact.

How many such return points is your hurdle, and how you want to register them.