Gas station without pumps

2016 February 1

Ultrasonic rangefinder project

Filed under: Data acquisition,freshman design seminar — gasstationwithoutpumps @ 23:00
Tags: ,

I’ve been thinking some more about the ultrasonic rangefinder project for the freshman design seminar.  I ordered the 40kHz transmit/receive transducers.  I ordered from two companies, both through eBay:

Both companies claim to have shipped via ePacket, with estimated delivery dates of Feb 5–Feb 27.  The early end would be much better—if it gets too late, I may have to order more expensive transducers from DigiKey.

What I’ve been thinking about is whether to have the students do a primarily analog or primarily digital range finder.  The analog method just times how long it takes until the return pulse is detected by the first  loud enough sound heard by the resonant receiver, and is what most of the cheap range finders do.  The digital method would record all the sound for about 17ms (for a maximum range of about 2.9m), then analyze it with a filter matched to the outgoing pulse.

The analog method is simpler, but has really crummy resolution, as the strength of the echo affects when it is detected (loud echos may be detected a cycle or two earlier than quiet echoes). An error of 2 cycles is 50µs, or 17mm.

The digital method requires fast sampling of the input—more than 340kHz to get 1mm resolution.  That is certainly doable on the Teensy boards (both the 3.2 and the LC), but would probably require using the direct-memory access (DMA) hardware to transfer to RAM, at least if the full 16-bit resolution is desired.  Programming the rather complicated DMA systems is certainly beyond the scope of the freshman design seminar, so I would have to provide the students with a routine that does the reading to RAM for them.  I’ll have to find out whether the students plan to use a Teensy 3.2 or a Teensy LC, since the two chips have rather different DMA capabilities, and I don’t want to have to figure out and debug both.

But if I only need 1mm resolution on the distance, that is 2mm resolution on the round-trip distance, so 170kHz is enough.  But signal processing may be easier if we keep to an integer number of samples for each half cycle, which would mean going up to 240kHz or down to 160kHz (1.06mm resolution).  The Teensy LC has only 8k bytes of RAM—if we reserve 512 bytes for stack and other uses, that leaves 7680 bytes for recording, or 3840 samples, for a range of 4m at 1.06mm resolution.  (The transmitter is probably not loud enough for a 8m round-trip echo to be usable—particularly not if we use just the 3.3V signals from the digital outputs.)

I wonder whether 160kHz is doable with the Teensyduino analogRead() interface? If so, the code may be doable by the students, without my having to write them a library routine.  I did a simple test on the Teensy to see how fast I could fill an array of 16-bit values:

void setup(void)

#define NUM_SAMPLES (2800)

uint16_t samples[NUM_SAMPLES];

void loop(void)
    long start=micros();
    for (int i=NUM_SAMPLES-1; i>=0; i--)
    {    samples[i] = analogRead(A0);
    long time=micros()-start;
    Serial.print(" samples in ");
    Serial.print(" usec, ");
    Serial.print(" usec/sample ");
    Serial.println(" Hz");

On the Teensy 3.1, I can get 171kHz with the 72MHz clock or 202.95kHz with 96MHz overclocking. I get 204.35kHz with 48MHz clocking, which is strange—why is it faster than the 96MHz? (All are “optimized” settings.) I understand why 72MHz is slower than 48MHz on the Teensy 3.1: the clock for the ADC has to be 2–12MHz for 16-bit conversions, and dividing down the clock by 4 on 48MHz gives 12MHz, and dividing down by 8 on 72MHz gives only 9MHz. But 48MHz and 96MHz should have the same ADCCLK (12MHz), and the overhead should be lower for the 96MHz clock—the difference is only a couple of instructions at 48MHz, but still, I don’t understand why the speeds are reversed from what I expect.

On the Teensy LC, I got about 155.6kHz, and I could only make the array about 2800 samples long (more RAM was needed for the stack and serial communication than I had expected). I don’t understand why the Teensy LC is so much slower than the Teensy 3.1 at the same clock speed—they should be almost identical. There could be some difference in the optimization—if I turn on optimization for the Teensy LC, it runs even slower and has less RAM available for the samples!  (It must be optimizing for flash memory size, which is the only resource I don’t care about here!)

Can anyone help me understand my anomalous timings?

In any case, it looks like the students could do an adequate job with just the Teensyduino interface on the Teensy 3.1/3.2, and the Teensy LC may just work with a range of about 3m and resolution of  1.1mm.

Detecting the echoes can be done fairly simply by a brute-force cross correlation of the expected pulse waveform with the returned signal.  If the pulse waveform is about 8 periods of 40kHz, then there would be about 32 multiply-adds per sample, or 90k multiply-adds for the 2.8k recording.  That should be doable fairly quickly and within the student programming capability, though there may be some problems with overflow using integer arithmetic.  Peaks that are higher than anything else within ±50µs and large enough to be above the noise floor could be taken as echos.  Some correction would be needed for the duration of the pulse.  Of course, the resonant receiver may be enough filtering, in which case only the peak detector is needed. I’ll look into whether a simpler IIR filter works better than correlating with the pulse waveform.

I’ll try recording a burst from the Maxbotix transmitter as seen by a non-resonant microphone, triggered by the Maxbotix pulse-width output, and see what it looks like (this will require some slight changes to the code, so I won’t get to it tonight.  I might want to look at the Ping))) output also.  The data will give me a better idea what sort of signal processing will be needed.


  1. […] still working on determining whether the ultrasonic rangefinder project is feasible for the freshmen in the design seminar. I don’t have the transmitters and […]

    Pingback by More testing for ultrasonic rangefinder | Gas station without pumps — 2016 February 2 @ 21:23 | Reply

  2. […] still working on doing the ultrasonic rangefinder project  myself, though I have already determined that it is feasible for the freshmen in the design […]

    Pingback by Ultrasonic rangefinder without amplifier | Gas station without pumps — 2016 February 12 @ 21:23 | Reply

  3. […] the series Ultrasonic rangefinder project , More testing for ultrasonic rangefinder, Ultrasonic rangefinders arrived, and Ultrasonic […]

    Pingback by Ultrasonic rangefinder with loudspeaker | Gas station without pumps — 2016 February 17 @ 23:30 | Reply

  4. […] the series  Ultrasonic rangefinder project , More testing for ultrasonic rangefinder, Ultrasonic rangefinders arrived, Ultrasonic […]

    Pingback by Ultrasonic transmitter impedance | Gas station without pumps — 2016 March 13 @ 13:00 | Reply

  5. […] still working on doing the ultrasonic rangefinder project  (In More testing for ultrasonic rangefinder, I gave a digital filter and showed it working with […]

    Pingback by Ultrasonic rangefinder tests with tiny loudspeaker | Gas station without pumps — 2016 August 18 @ 23:31 | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: