This is an addendum to the previous post, where I started sketching things for making a low-budget ultrasound camera (and stuff), but ran out of steam.
First point I wanted to add is that I know I am approaching this in a very naive fashion. Totally intentional, mostly because I don’t want to get bogged down in theory before I start playing. Frankly, I’m not very good at it. What I am pretty good at though is prototyping (not necessarily rapid). Learn along the way.
I said previously I believed it was possible to capture data, using a simple hardware configuration that was “somehow related to the characteristics of the space in front of the transducers”.
Basic acoustics is one thing, but generally speaking the field can get very hard very fast. Take for example the idea of simply measuring the distance of an object by means of pulse-echo timing. This works fine for a perfect reflector in a homogeneous medium, but the real world ain’t like that. A pulse could be scattered all over the place, the medium and or object might not static, the target might absorb some of the sonic energy. All kinds of variables. When I’m talking about using the amplitude of pulses rather than echo timing, that’s another layer of complexity. The attenuation of a sound wave over distance can be approximated by an inverse-square law. A better approximation can be derived from using Stokes’s law of sound attenuation, which is a power law. Or better still, Navier-Stokes equations, which start hard and get harder, there’s even a million-dollar prize associated.
So I think being naive is a rational strategy. Defer the hard bits as long as possible (and hopefully avoid altogether). Many kinds of similar data have been shown to yield to current Deep Learning techniques. Worth noting that many traditional methods of acoustic analysis use techniques intimately related to convolutional neural networks (correlation, autocorrelation, Fourier analysis and, er, convolution applied to time series).
An aspect of my personal approach to (not-necessarily-rapid) prototyping is that I can spend weeks, months, years even, mulling over things in between phases of actually building stuff. As far as Getting Things Done, maybe not the optimal strategy, but does have two distinct plus points. One is, my slow brain often comes up with a much simpler solution after extended periods of inaction. The second, an instance just occurred to me, is coincidence of problems from different projects.
For a while now I’ve been working on an analog computer, notes up on GitHub. Possibly the most important parts of such a system are integrator modules. The basic circuit is trivial (a resistor feeding a capacitor). This can be made more generally useful in practice with the addition of active components (typically operational amplifiers, exactly the kind of thing they were designed for). But for a versatile analog computer, this thing really needs control over its states : initial conditions; running; paused; reset to initial conditions. Ideally this will allow external control, eg. from a microcontroller.
What’s very sweet about this is that part of my motivation for making an analog computer was that I thought it might give me insights into other problems. Got one, even before I’ve built the thing!
I did think the idea of using 4xDACs + 4xVCAs for raster-scanning impulse levels was over-engineering. I want two synchronized, but otherwise independent series of impulses of linearly increasing amplitude.
Ah. A synchronized, gated ramp.
Feed a constant positive value into an integrator, you get an uphill ramp, it’s just linearly adding. If you can pause this, then flip a switch momentarily, connecting the current value to the output (transducer), there’s a series.
This is very close to a well documented circuit type used in early data acquisition, the sample & hold. Also contemporaneously used in LCD displays. Serendipitously used a lot in 1970’s analog music synths for monophonic keyboard note capture, hence there should be plenty of hacky versions around…
(Without looking, longest word in that paragraph?)
Ok, so timing constants might potentially be an issue around this around the analog circuit. But there is a big window – low end, how well do the analog parts behave, high end the capture time, need to get the responses.
Not unrelated, a potential dimension of nightmare, the sample rate of the response capture circuit. But sound in air only travels ~34cm in a millisecond [check sums danny!], and I’m thinking of dealing in impulses, which, even if (in practice) they only last microseconds, can be cough, integrated down to a longer time scale, show up at say 44.1kHz sampling, that’s straightforward with regular audio-ish frequency analog electronics.
I need to get some measurements from the 40kHz transducers. They surprised me, with initial play, I foolishly imagined they did great at 40kHz, near nothing elsewhere. But seem really responsive way up even beyond the 10th harmonic. I suppose physics kinda dictates that. Not strictly relevant to my naive approach, but do need to find good driving voltages etc.
Ballpark, as gathered from the limited datasheets I could find, these things can take >10v, but 18v risking burnout (not exactly, physics again, probably talking about physical breakage of a crystal if it’s made to twitch too much).
Coincidentally…very close to what I want for the analog computer. +/-10v as a good value range on which to operate op amp signals, they being supplied with +/-15v.
This is beyond what cheap analog switching chips can do. But this is the kind of thing FETs are good at (as inside those chips, but discrete components, bit more balls). So time needed on the breadboard. I have a few 2N7000 MOSFETs and 3? 2N3819 JFETs. What I’ve read, the JFETs probably have more useful characteristics (notably on/off resistance ratio).
I need to put the physical bits together – have already drilled out an aluminium plate to hold the transducers. But want to take measurements first, check polarities, kind of receive signals need to be handled etc.
Then breadboard, breadboard,breadboard.
Oh yeah, and decide on a framework for the Deep Learning bits, look for similar algorithms/models. I am sorely tempted to go with Tensorflow Lite, so it could run on the microcontroller, but for now that’s probably being silly. Probably go with PyTorch so I’ve more of a clue what is going on, let laptop do all the sums.