Keith's Electronics Blog

I haven’t touched the DIY rangefinder project for a couple of weeks, but I realized I also never wrote up my latest work on it.

Receiver Comparator

After my previous post about building two amplifier stages, I intended to use one of the spare channels on the LM324 as a comparator to “digitize” the amplified receiver signal and provide a clean input to the LogoChip. Unfortunately, the first time I prototyped it was late in the evening when my brain doesn’t work too well, and I built it just like the first two stages–as a linear amplifier. I was really surprised to see more analog waveforms on my scope when I expected sharp edges. At only 24kHz, I didn’t think it should be a slew rate problem, but I wasn’t thinking clearly and just set it aside for the night.

The next day, my error was obvious, and I pulled out the feedback resistor to let the op amp run open loop with infinite gain. It cleaned up the signal, although still not as much as I would have expected. Once the basic circuit was working, I replaced the fixed voltage divider with a 20k trimpot and tuned it as well as I could, trying to find the sweet spot to weed out all the noise but pass all the real signals.

I hadn’t seen it before, but now I wondered whether I was getting some false readings from noise, as John suggested he had encountered when working on similar circuits. I looked briefly at adding a low-pass filter to the circuit (it’s already high-pass filtered by the capacitive coupling from the receiver to the first amplifier stage due to the single-ended op-amp I’m using), but haven’t done it yet. First I wanted to connect it to the LogoChip and see what kind of results I got.

PIC CCP

An ultrasonic rangefinder measures distance by emitting a “ping” and counting the time until the echo is detected; dividing by the speed of sound translates the round-trip time into a distance. Because of the short durations involved, the easiest way to do this on a PIC microcontroller is with the “capture” section of the Capture/Compare/PWM (CCP) subsystem. It uses a high-resolution timer and interrupt circuitry to give a very precise measurement of how long something takes to happen.

I started with John Harrison’s CCP code from his srf_demo.txt example on the TechArt wiki LogoChip with Ultrasonic Sensor page. His code was using the PIC’s CCP module #1; but in my application, I was already using CCP1 to provide the 24kHz signal for my transmitter, so I started translating to use CCP2. The control and behavior of the two CCP channels are rather different, so it wasn’t a matter of simple substitution. Here’s what I ended up with:

• ultrasonic.txt – Program to drive ultrasonic rangefinder

Here’s the receiver section of the code:

;------------------------------------------------------------------------------
;   Routines for manipulating CCP2 and timer 3 for capture.
;------------------------------------------------------------------------------

constants [
    [CCP2CON $fba]                      ;   capture/compare/PWM 2 control reg
        [CCPxM-CAP-EVERY #0100]                 ;   capture every falling edge
    [CCPR2H $fbc]                       ;   CCP 2 register low byte
    [CCPR2L $fbb]                       ;   CCP 2 register low byte
    [PIR2 $fa1]                         ;   peripheral interrupt request 2
        [CCP2IF 0]                              ;   timer 3 interrupt bit
    [CCP2-PORT portc]                   ;   uses portc pin 1
        [CCP2-BIT 1]
    [CCP2-DDR portc-ddr]

    [T3CON $fb1]                        ;   timer 3 control register
        [T3CCP2 6]                              ;   timer 3 CCP mode bit 2
        [T3CCP1 3]                              ;   timer 3 CCP mode bit 1
                                                        ;   1x src CCP1+2
                                                        ;   01 src CCP2
        [T3CKPS1 5]                             ;   timer 3 prescale bit 1
        [T3CKPS0 4]                             ;   timer 3 prescale bit 0
                                                        ;   11 = 1:8
        [TMR3ON 0]                              ;   timer 3 enable bit
    [TMR3H $fb3]                        ;   timer 3 high byte
    [TMR3L $fb2]                        ;   timer 3 low byte
]

;   Initialize CCP by configuring timer 3 and enabling capture mode.
to ccp-init
    write CCP2CON CCPxM-CAP-EVERY       ;   config to capture every falling edge

    clearbit T3CCP2 T3CON               ;   set T3CCP to 01 to make T3 src CCP2
    setbit T3CCP1 T3CON                 ;       and T1 src CCP1

    setbit T3CKPS1 T3CON                ;   set T3CKPS to 11 to use 1:8
    setbit T3CKPS0 T3CON                ;       prescalar

    setbit TMR3ON T3CON                 ;   enable timer 3

    setbit CCP2-BIT CCP2-DDR            ;   set CCP2 (RC1) pin for input
end

;   Record starting value of timer 3 and clear capture flag.
global [ccp-before]
to ccp-start
    setccp-before ((read TMR3H) * 256) + read TMR3L
    clearbit CCP2IF PIR2
end

;   Wait for capture event and return duration.
global [ccp-after]
to ccp-wait
    waituntil [testbit CCP2IF PIR2]     ;   wait for capture interrupt
    setccp-after ((read CCPR2H) * 256) + read CCPR2L
    output ccp-after - ccp-before
end

I added code to send a ping and take a measurement:

;------------------------------------------------------------------------------
;   Top-level routines to tie it all together.
;------------------------------------------------------------------------------

;   For the sake of testing, activate on powerup.
constants [[standalone 0]]
to powerup
    pwm-init
    ccp-init
    if standalone [ pwm-on ]
end

;   Send a short burst of tone.
to ping
    pwm-on
    mwait 1
    pwm-off
end

;   Ping and measure time to reply.
to range
    ccp-start                           ;   record start time
    ping
    output ccp-wait                     ;   wait for echo and return duration
end

Wrote a little loop to display the results on the PC, and was disappointed to see that they really didn’t vary at all in proportion to the distance from the sensor to an obstacle. After a few minutes of head-scratching, I noticed that I hadn’t wired the comparator output to the LogoChip’s CCP input. Oops! And that’s when I realized I had a much bigger problem.

Overloading Port C1

The PIC’s CCP modules are implemented in hardware, and they’re hard-wired to specific pins. The input pin for CCP2 is the same as general-purpose pin C1–in fact, most if not all of the PIC’s pins have multiple functions that are selected by configuration registers.

My problem arose because C1 is already being used by the LogoChip firmware–as the Go/Stop input! Because LogoChip Logo isn’t open-source, I can’t see exactly how it’s being used, and have to guess what would happen if I tried to use it as a capture input. Since pressing a button attached to that pin makes the LogoChip stop executing user code and return to an idle state, I can’t imagine I’d have an easy time overriding that behavior and getting it to use the pin solely for CCP with no interference.

So what now? I need both CCP modules–one to use the PWM output to drive the 24kHz transmitter, and the other to watch and count time on the receiver. I don’t think I’ll be able to overload C1 with CCP2 for the receiver, so I’m left with a couple of options: swap the pins, or use CCP1 for both transmission and reception.

Swap the Pins

My first thought was to use CCP1 as the receiver (since its corresponding port, C2, is otherwise unused) and make CCP2 the transmitter (on port C1, the Run/Stop button). John says he has previously overridden C1 and used it as an output when the Run/Stop functionality wasn’t needed, so this should work.

In the long run, though, I’m a little uncomfortable giving up the Run/Stop button. I’d like to be able to integrate this technology into hobby robots, and I’d like to be able to leave them powered up but in an idle state, without having to duplicate the preexisting Run/Stop behavior myself in software. Swapping the PWM-transmit / capture-receive pins should work for a quick fix, but I’m not sure it’s where I want to be in the larger game.

Use CCP1 for Both Transmission and Reception

Alternately, I could overload CCP1 for both transmitter and receiver. There’s precedent–another student in class is using the Parallax PING))) ^(TM) sensor module, which has only three pins–ground, power, and bidirectional signal.

To do that, I’d need to make sure that transmission and reception don’t interfere with each other. Keeping transmissions out of the receiver circuit is easy–put a diode from the comparator output to the LogoChip so the transmitter signals don’t go “upstream” into the comparator.

Keeping comparator signals out of the transmitter driver is a little trickier, but I think I have a reasonable solution, based on something I was considering doing anyway. I’d like to be able to drive multiple sensors from one LogoChip, but there’s only one (er, two, maybe, sorta) PWM output available. To drive multiple rangefinders, I’d need to multiplex the PWM signal somehow–and there are plenty of ways to do that.

The most straightforward is to use a few LogoChip output pins to select which transmitter to drive and AND (or NAND) them with the PWM signal. Cake! And it tidily solves my receiver-interfering-with-transmitter problem–the receiver can dump whatever it wants onto the PWM output, but it won’t go anywhere harmful unless one of the transmitter select lines is activated.

Sounds like a win all around, and I think I’ll investigate it as soon as things calm down with the exhibit and I can get back to tinkering. It means a little more work on the software side (switching CCP1 back and forth between PWM and capture modes), but I’ve never been afraid of writing code.

Last night, I prototyped the transmitter circuit; today, I worked on the receiver. Coe’s design uses a two-stage op-amp circuit, with AC coupling on the input from the transducer to the first stage, to amplify the received signal before sending it to a comparator. I wanted to do the same, but I prefer to run from a single supply voltage, so I used an LM324 and added voltage dividers to bias the signal up to 2.5V.

First, I powered up the circuit from last night and measured the receiver’s signal on my scope. With the transmitter and receiver about 2” apart, the receiver signal was about 2V peak-to-peak, attenuating to about .5V p-p at 2’. If it continues to attenuate by a factor of 10 every 2’, then to measure distance out to 10’ (round trip of 20’), the received signal would be 2 * 10^-10, or .2nV. Let’s hope that’s not the case!

The Circuit

Each stage of the amplifier circuit is taken directly from the LM324 datasheet, “AC Coupled Inverting Amplifier” (although the two stages are DC coupled). The receiver’s signal is AC-coupled to the first amplifier’s inverting input, with a 2.5V bias to the non-inverting input.

I’m not sure why C₁ is needed on the bias voltage divider, but the output waveform was considerably cleaner with it than without, so I left it in. I also don’t know what R_B does, and Forrest Mims’ Engineer’s Mini Notebook on op-amp circuits didn’t show it but the datasheet did, so I left it in as well.

Values

The bandwidth-gain product for the LM324 is 1MHz, so a 24kHz input means the maximum possible gain is about 41.7. The gain is set by the quotient of the feedback and input resistors, and it worked very naturally to select R_F = 1MΩ and R_IN = 24kΩ.

According to Mims, C_IN should have a value of 1 / (2π f_low R_IN), where f_low is the lowest frequency to pass the filter. This gives C_IN = 1 / (2π 24kHz 24kΩ) ≅ 280pF–except the first time around, I mistakenly calculated using R_F (1MΩ) instead of R_IN (24kΩ), and got 6.6pF. I had a 10pF on hand, so I substituted it; but it was still far too low a value, as will be seen shortly.

I breadboarded the circuit on my workbench and measured about .04V peak-to-peak directly from the receiver element, with both transducers pointed at the ceiling. (That was about an 8’ round trip, so my dire prediction of .2nV was fortunately not the case.) Next, I measured only about .08V p-p at the output of the first amplifier stage, so obviously something was wrong. It was at this point that I added C₁, which brought the amplifier output to about .1V and cleaned it up dramatically–but with a gain of 40, it should have been more like 1.6V.

I was suspicious about the value of the AC coupling capacitor, C_IN, and began substituting different values for it, with the following results:

It looked like I must have miscalculated by an order of magnitude (at this point, I hadn’t yet caught my frequency error in the calculation), and 100pF was probably close to the best valued, but still a little too far down the knee of the filter’s response curve. .6V output was still a little low for a gain of 40, but within a range I was willing to accept, given that I was estimating the values by counting hashmarks touched by a dirty, wiggling waveform on my scope. I put the 1nF back in and called it good.

Second Stage

After honing the values on the first stage of amplification, the second stage was easy–just more of the same. I used all the same values, but omitted the AC coupling capacitor, since I’m happy to DC-amplify around the 2.5V bias. The second stage gives me a trapezoidal waveform (clipping both the top and bottom of the transducer’s sine wave) running rail-to-rail of the LM324′s advertised output capacity–from 0V to about 4V. Tomorrow I need to run that through a comparator to clean it up just a little more, and then steal John’s capture/compare LogoChip code to start timing the echoes.

Ultrasonic rangefinders detect objects and measure distance the same way as a bat: Emit a high-pitched “ping” and measure how long it takes the echo to return. The speed of sound in air is nearly constant (ignoring slight variations due to air pressure and humidity), so the time from ping to echo translates directly into the distance to the object.

I’m interested in ultrasonic rangefinders for both hobby robotics and our TechArt final project. They’re available commercially, but $25 each adds up pretty fast if you need multiples to establish a view all around a bot or across the wide front of an art installation. All Electronics has transducer elements for $1 each in quantities of 10 or more, so I ordered a batch of them in hopes of building a rangefinder myself. At $2 each (two transducers, for send and receive), I can add a fair bit of supporting circuitry before hitting the $25 mark.

The Plan

I’m basing my circuit on a design by Gerald Coe at http://www.robot-electronics.co.uk/htm/srf1.shtml, and adapting it for different design goals. His circuit uses a dedicated PIC to provide the oscillator, a MAX232 to generate 16V to drive the transmitter, and 40kHz transducers. For now, I want to run my rangefinder from an existing LogoChip that’s also doing other work, avoid the complexities the MAX232 adds, and use transducers with a different nominal frequency. Later, I might build separate modules intended to stand alone and run with very low power.

Initial Testing

According to a comment on the All Electronics page for the transducers I ordered, they run at 24kHz. The first order of business was confirming that operating frequency.

I hooked my function generator to my frequency counter and scope and dialed in 24kHz, to make sure I was in the neighborhood before connecting the transducer. I then connected one transducer to the function generator to serve as the transmitter (with the frequency counter still attached), and the other transducer to the scope to serve as the receiver.

When I pointed the transmitter at the receiver, a signal showed up on the scope; when I pointed it away, the signal abated. I could bounce it off my hand and receive it, but not off the ceiling. (I’m guessing the elements weren’t aimed well enough and/or the amplitude wasn’t high enough.) And changing the oscillator frequency confirmed that 24kHz is indeed optimal.

So the project is at least possible. That’s a good start!

Connecting the LogoChip

I really didn’t feel like disassembling my balance-bot project, so I’m sure glad I bought several PICs! I built up a breadboard with another LogoChip on it and verified operation. Then I took my motor-control PWM code and cleaned it up to generate a single frequency signal.

Testing with my frequency counter and scope hooked up, it looks like I need timer 2 with a prescalar of 1 and a period of 82 to get as close as possible to 24kHz. Hm, 82 * 24k ≅ 2M, which tells me that I really don’t understand what timer 2 is using for an input clock. Wait–yes, I got it. The PIC has an internal 4x increase in oscillator speed, so the 2Mhz timer oscillator leads to the 10Mhz clocking.

Driving the Transmitter

I first tried powering the transmitter element with an NPN driver, for simplicity and to allow experimentation with the drive voltage:

I connected the receiver element to my scope to detect the signal, and was surprised to detect nothing. I looked back at Coe’s schematic and noticed that he drives his transmitter in a push-pull arrangement using the MAX232, so I scrounged around for something with totem-pole outputs that I could use to test. The quickest thing I could come up with was a 7404:

And this time, I did show a received signal on the scope, albeit a slightly weak one; so I guess the push-pull drive is necessary.

I’m not satisfied being restricted to a 5V drive, because Coe specifically mentions using 16V to get adequate detection at greater range. However, I’m not sure I have anything on hand that will do exactly the right job and which I’m happy using. None of the options quite work out:

• The 74xx chips with “high-power output” and 754xx peripheral drivers run open-collector, and I don’t see a good way to use that to provide push-pull.
• The 754410 H-bridge driver adds about $2 to the cost–not bad, but I’d rather avoid it if I could.
• The MAX232 adds about $1 plus numerous supporting components–and Coe mentioned that it generates enough noise that he shut it down after each ping to keep it from interfering with the echo detection circuitry.

I’ll probably prototype with the 754410 since I have some on hand, and keep looking for other options.