Gas station without pumps

2017 February 6

Hysteresis oscillator is voltage-dependent

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 20:42
Tags: , , ,

Today in class I did a demo where I tested the dependence of the frequency of my relaxation oscillator board on the power supply voltage.

The demo I did in class had to be debugged on the fly (it turns out that if you configure the power supplies of the Analog Discovery 2 to be low-speed waveform channels, then you can’t set them with the “Supplies” tool, but there is no warning that you can’t when you do the setting), but otherwise went well.

One surprising result (i.e., something else that hadn’t happened when I tested the demo at home on Sunday) was that the frequency appeared to go up instead of down when I touched the capacitive touch sensor.  This I managed to quickly debug by changing my sampling rate to 600Hz, and observing that the 60Hz frequency modulation was extreme at the podium, taking the oscillation frequency from 0Hz to 3MHz on each cycle.  Grounding myself against the laptop removed this interference and produced the smooth expected signal.

Anyway, when I got home I was much too tired to grade the lab reports turned in today (I’ve got a cold that is wiping me out), so after a nap and dinner, I decided to make a clean plot of frequency vs. power-supply voltage for my relaxation oscillator.  I stuck the board into a breadboard, with no touch sensor, so that the capacitance would be fairly stable and not too much 60Hz interference would be picked up.  I powered the board from the Analog Discovery 2 power supply, sweeping the voltage from 0V to 5V (triangle wave, 50mHz, for a 20-second period).

I used the Teensy LC board with PteroDAQ to record both the frequency of the output and the voltage of the power supply.  To protect the Teensy board inputs, I used a 74AC04 inverter with 3.3V power to buffer the output of the hysteresis board, and I used a voltage divider made of two 180kΩ resistors to divide the power-supply voltage in half.

When I recorded a few cycles of the triangle waveform, using 1/60-second counting times for the frequency measurements, I got a clean plot:

At low voltages, the oscillator doesn't oscillate. The frequency then goes up with voltage, but peaks around 4.2V, then drops again at higher voltages.

At low voltages, the oscillator doesn’t oscillate. The frequency then goes up with voltage, but peaks around 4.2V, then drops again at higher voltages.

I expected the loss of oscillation at low voltage, but I did not expect the oscillator to be so sensitive to power-supply voltage, and I certainly did not expect it to be non-monotone.  I need to heed my class motto (“Try it and see!”) more often.

Sampling at a higher frequency reveals that the hysteresis oscillator is far from holding a steady frequency:

Using 1/600 second counting intervals for the frequency counter reveals substantial modulation of the frequency.

Using 1/600 second counting intervals for the frequency counter reveals substantial modulation of the frequency.

This plot of frequency vs. time shows the pattern of frequency modulation, which varies substantially as the voltage changes, but seems to be repeatable for a given voltage. (One period of the triangle wave is shown.)

This plot of frequency vs. time shows the pattern of frequency modulation, which varies substantially as the voltage changes, but seems to be repeatable for a given voltage. (One period of the triangle wave is shown.)

Zooming in on a region where the frequency modulation is large, we can see that there are components of both 60Hz and 120Hz.

Zooming in on a region where the frequency modulation is large, we can see that there are components of both 60Hz and 120Hz.

I could reduce the 60Hz interference a lot by using a larger C and smaller R for the RC time constant. That would make the touch sensor less sensitive (since the change in capacitance due to touching would be the same, but would be a much smaller fraction of the total capacitance). The sensor is currently excessively sensitive, though, so this might be a good idea anyway.

2017 January 8

Applying for Mini Maker Faire 2017

Filed under: Uncategorized — gasstationwithoutpumps @ 17:41
Tags: , , , ,

I’m submitting an application for the Santa Cruz Mini Maker Faire 2017 (2017 April 29), since last year’s Mini-Maker Faire went well (see Santa Cruz Mini Maker Faire went well).  This year I’m getting my application in early, rather than dithering about it for months as I did last year.  I have less free time to prepare the display this year, but I have a better notion what I want to do, so it should not take long to get ready.

Last year's banner, which I can reuse this year. I might also make a shorter one that will fit on the front of the table.

Last year’s banner, which I can reuse this year. I might also make a shorter one that will fit on the front of the table.

The “non-public” description of my display is straightforward:

I’ll bring a tabletop full of electronics projects, as last year (see https://gasstationwithoutpumps.wordpress.com/2016/04/16/santa-cruz-mini-maker-faire-went-well/ ).

Laptops demonstrating free software to turn cheap microprocessor boards into data-acquisition systems suitable for home labs and science-fair projects.
Homemade LED desk lamp and stroboscope.

Several of the projects will be interactive (an optical pulse-rate monitor, oscillators that can be adjusted to change Lissajous figures on an oscilloscope, …).

A few changes from last year: a more reliable pulse-monitor design and a new USB oscilloscope.

The public blurb is similar to last year’s:

See your pulse on a home-made optical pulse monitor!
Record air pressure waveforms using free PteroDAQ data acquisition software!
Play with a bright custom-design LED stroboscope!
Control fancy Lissajous patterns on an oscilloscope!

I removed mention of an EKG, because I decided that it was too much trouble to tether myself with EKG leads all day.

My “Maker bio” is a bit boring, :

Kevin Karplus has been an engineering faculty member at UCSC since 1986, but has done hobbyist electronics on-and-off since the 1960s. For the past few years he has been working on a low-cost textbook to make hands-on analog electronics accessible to a wider range of students.  Several of the projects on display are from the textbook.

2016 October 2

Pulse monitor using log amplifier

I am currently rewriting the optical pulse monitor lab for my Applied Electronics for Bioengineers book, because I’ve moved it earlier in the course, and because I need to remove the calculation of how big the signal should be, which never worked out very well.  There were way too many assumptions in the calculation, and it turned out to be much easier and more accurate to “try it and see” than to do the calculations.

I always do the labs (often several times in different ways) while writing the lab chapters, so I’ve been playing with pulse monitors again.  I’ve decided that I will definitely have the students do a logarithmic transformation of the photocurrent to voltage, as that eliminates the need to guess a resistance value for the first-stage amplifier.  The amplifier can be designed in two stages, with the first one doing the logarithmic conversion and the second one providing sufficient gain over the desired frequency range (where “sufficient” gain is determined by measuring the output of the first stage).

In Using 4¢ diode for log-transimpedance, I talked about using a 1N914 diode as the feedback element of a transimpedance amplifier to get an output voltage as (roughly) the log of the input current.  There are actually two circuits that are subtly different ways to convert the log of current to voltage:

Two circuits that convert the logarithm of light intensity to voltage.

Two circuits that convert the logarithm of light intensity to voltage.

One of the exercises in the book is to compare the circuits (particularly looking at the constraints on what Vref can be in each).

Because I’d not played with it before, I tried using the unity-gain buffer design this weekend, to make sure the circuit worked and to see whether a single-stage amplifier provided enough signal to record with PteroDAQ using the 16-bit ADCs in the Teensy boards. I was also interested in trying out a new design for holding the phototransistor, so that students could experiment with ambient-light pulse monitors and cisillumination, where the illuminating LED is on the same side of the finger as the phototransistor.  In previous years we have always used transillumination, shining the light through the finger, but most wearables use a cisillumination design, because it is mechanically simpler and much cheaper to make.

I played around with a couple of different ways to make a finger cradle and ended up with the following design:

This is cut from a scrap of some softwood (pine? fir?), with a 1" diameter hole for the finger, a ¼" hole at right angles for the wires, and two ⅛" holes between them for the 3mm LED and phototransistor.

This is cut from a scrap of some softwood (pine? fir?), with a 1″ diameter hole for the finger, a ¼” hole at right angles for the wires, and two ⅛” holes between them for the 3mm LED and phototransistor.

The finger cradle worked great for ambient light, but when I tried using it for cisillumination, I could not get it to work—I had plenty of photocurrent, and if I modulated the LED the photocurrent was modulated, but I never saw a fluctuation that corresponded to the pulse in my finger. It turned out that the problem was that the wood is too transparent—I was getting so much light through the wood, that the fluctuation in what was returned from my finger was a tiny fraction of the total light—too small to be visible above the noise floor.

I mentioned this problem to my wife, who suggested I use black electrical tape. I’m not sure she quite understood the problem, since the wood was solid between the LED and phototransistor, but her solution was a good one—I just needed to put the tape in the middle of the block of wood!

By cutting between the two 3mm holes I could put black electrical tape to block the short-circuiting light path.

By cutting between the two 3mm holes I could put black electrical tape to block the short-circuiting light path.

With this design I could get small but recordable signals with either ambient light or cisillumination:

Response of first stage amplifier with an LED desk lamp shining through my left thumb.

Response of first stage amplifier with an LED desk lamp shining through my left thumb.

Output of first stage using an IR emitter on the same side of the left thumb as the phototransistor.

Output of first stage using an IR emitter on the same side of the left thumb as the phototransistor.

Both the plots above are a little misleading, as they were sampled at 60Hz, to alias out any 60Hz or 120Hz interference. With steady bright light from my LED desk lamp, I got similar plots even at 600 Hz, but with compact fluorescent illumination, the signal was buried in 120 Hz interference:

With 600 Hz sampling, it is easy to see the effect of modulated light.

With 600 Hz sampling, it is easy to see the effect of modulated light.

I don’t particularly like the electrical tape and wood approach to making the finger cradle—it is a bit fragile, and the tape needs to be replaced frequently.  Furthermore, ambient light reaches the phototransistor through the sides and ends of the block, unless the whole thing is wrapped in electrical tape. I think that I’ll buy a chunk of black ABS plastic and try making the whole thing out of it. I can probably get a dozen finger cradles out of a 1′ length of plastic, if I don’t mess anything up (and if all my drills work with ABS—I’ve never worked with ABS as anything but Lego bricks).  Another alternative is to go to the hardware store and see how thick the black ABS couplers are—I might be able to make a finger cradle by cutting one in half lengthwise, if the wall thickness is at least 6mm.  I’d still have to add something to keep it from rolling around.

In the past, I’ve thought about using pulsed light to make pulse monitor measurements that are less sensitive to fluctuations in ambient light. The idea is that I would make a measurement with the LED off, turn the LED on, wait a little while for the sensor to settle, then make another measurement. The difference between the measurements would be due just to the LED light, if the ambient light is changing slowly enough not to be very different between the measurements. I’m not sure that this is a good idea (the large change in light level means that there would have to be less analog amplification than for steady illumination, for example), but I was curious how long the on-pulse would have to be to get good measurements.

I hooked the IR emitter up to a hysteresis oscillator, to get nice sharp square waves, then recorded the output of the amplifier with my Bitscope USB oscilloscope. I used the differential probe to get an extra gain of 5 and AC coupling. I recorded 1156 traces, then used my retriggering and averaging program to superimpose and average the pulses. I ended up with between 2300 and 3500 pulses being averaged (depending where on the waveform you look).

The circuit responds fairly quickly to a rising edge, roughly like having an RC time constant of 84.5µs.

The circuit responds fairly quickly to a rising edge, roughly like having an RC time constant of 84.5µs.

The response to a falling edge is slower, roughly like an RC time constant of 207.8µs.

The response to a falling edge is slower, roughly like an RC time constant of 207.8µs.

The response to rising and falling edges is quite different, because of the nonlinear nature of the diode. When we are charging the parasitic capacitance, we have a fairly large photocurrent to do it with, but when we are discharging, the current gets quite small as the voltage across the diode drops. With a linear system, response to a positive step and negative step would be identical, except for the sign.

Both response times are fast enough that the shape we were seeing for the pulse waveforms is due to changes in the opacity of the finger, not due to distortion or filtering in the amplifier.  There is a sudden increase in opacity, followed by a gradual recovery as the blood flows through the capillaries and veins out of the thumb.

If I were to try the difference between LED-on and LED-off measurement, I’d want to have the LED on for at least 400µs, then off for at least 1ms.  (I’d probably do on for 400µs, then off until the next 1/60s tick, making a 2.4% duty cycle for the LED.)

Note also that the 50mV swing here is much larger than the 3mV swing that I got from pulse measurements, so gain would have to be limited to avoid clipping.

2016 September 27

Teensy 3.5 & 3.6 Kickstarter

Filed under: Uncategorized — gasstationwithoutpumps @ 16:59
Tags: , , ,

As many of the followers of my blog know, the Teensy 3.1 and Teensy LC have been my favorite microcontroller boards for the past couple of years.  The Teensy 3.1 has since been replaced by the slightly better Teensy 3.2, which has a better voltage regulator but is otherwise pretty much the same as the 3.1.  I’ve been using the Teensy LC with PteroDAQ software for my electronics course.

I’ve just noticed that PJRC has a Kickstarter campaign for a new set of boards the Teensy 3.5 and 3.6.  These will be much more powerful ARM processors (120MHz and 180MHz Cortex M4 processors with floating-point units, so at least 2.5 times faster than the Teensy 3.2, more if floating-point is used much).  The form factor is similar to before, but the boards are longer, taking up 24 rows of a breadboard, instead of just 14.  The extra board space is mainly to provide more I/O, but there is also a MicroSD card slot.

The designer is still dedicated to making the Teensy boards run in the Arduino environment, and the breadboard-friendly layout is very good for experimenting.

PJRC is positioning the new boards between the old Teensy boards and the Linux-based boards like the Raspberry Pi boards. The new Teensy boards will have a lot of raw power, but not an operating system, though I suspect that people outside PJRC will try porting one of the small real-time operating systems to the board.

The new boards are a bit pricey compared to the Teensy LC ($23–28 instead of under $12 for the Teensy LC), but still reasonable for what they provide.  PJRC also has a history of providing good software for their boards.

I probably need to get both a Teensy 3.5 and a 3.6 to port PteroDAQ to them—that looks like a $50 purchase. If the boards and the software are available in time for me do development on PteroDAQ by December, I might get it done—any later than that and I’ll have no time, as I have a very heavy teaching and service load for Winter quarter.

I suspect that the new Teensyduino software will need a newer version of the Arduino development environment, which in turn would require a newer version of the Mac operating system (my laptop is still running 10.6.8), which in turn probably means a new laptop.

I’m waiting to see if Apple releases a new, usable MacBook Pro in October, so there is a bit of built-in delay in the whole process. I’m not impressed with their recent design choices for iPhones and MacBook Air—I need connections to my laptop—so there is a strong possibility that I may be having to leave the Macintosh family of products after having been a loyal user since 1984 (that’s 32 years now).

Update 2016 Sep 27: I just watched the Kickstarter video.  They used the Karplus-Strong algorithm as a demo.  Of course, that demo could have been done on a Z80 chip from 1976 (though not easily—the sampling rate suffered a bit to run 4 strings on the Z80, and only 8-bit DACs were affordable in those days).  It would have been more instructive to do an FM synthesis algorithm, which takes a lot more processor power than Karplus-Strong.

2016 September 5

Improved spectral response for dehumidifier noise

Filed under: Data acquisition — gasstationwithoutpumps @ 14:29
Tags: , , , , , ,

In Dehumidifier, I provided spectral analysis of the sound from the 30-pint Whynter RPD-321EW Energy Star Portable Dehumidifier, using my BitScope USB oscilloscope to record the sound and averaging the absolute value of the FFT over 100 short traces. Today I decided to improve the FFT analysis by using the scipy.signal.welch() function to split a longer trace into windows, apply a Dolph-Chebyshev window-shaping function, and average the resulting power spectra. The main improvement here is the use of the window-shaping function.

I used PteroDAQ with a Teensy LC board to record at 15kHz, which was as fast as I could go with 4× averaging communicating with my old MacBook Pro laptop. Based on the Bitscope recordings, though, that should include all the interesting signal, which appears to be limited to about 5.4kHz. I could only record for about 330,000 samples to avoid overrunning the USB buffer and dropping samples, so I also tried 12kHz, which allowed me to run longer. The analysis looked much the same, with no apparent reduction in the noise floor, so I’ll only present the 15kHz results. (Note: when I get a new laptop this fall, I should be able to run at this sampling rate for much longer, which should allow smoothing out more of the noise.)

The dehumidifier looks very much like 1/f noise, with a big spike around 1050Hz. The spikes at 60Hz, 120Hz, 240Hz, and 360Hz may be electrical noise picked up by the sound amplifier, rather than acoustic noise.

The dehumidifier looks very much like 1/f noise, with a big spike around 1050Hz. The spikes at 60Hz, 120Hz, 240Hz, and 360Hz may be electrical noise picked up by the sound amplifier, rather than acoustic noise.

Using Welch’s method and a proper window function results in a much cleaner spectrum than before. I used a 216 FFT window for the analysis, since I had plenty of data, which gives a fairly fine resolution of about 0.23Hz. The 60Hz spike is appearing at 58.36Hz, which is a little troubling, as the PteroDAQ crystal and the power company both have better frequency control than a 2.7% error. The 120Hz, 240Hz, and 360Hz spikes are at most one bin off from where they should be, so I don’t understand the shift at 60Hz.

I checked my code by testing with a recording of a triangle wave, and found that Welch’s method with an 80dB Dolph-Chebyshev window did an excellent job of removing the spectral smear that I was getting by just averaging rectangular FFT windows (my first approach). The noise floor for Welch’s method on those measurements was pretty much flat across the entire spectrum (maybe rising at higher frequencies), so the 1/f plot here is not an artifact of the analysis, but a real measurement of the acoustic noise. Using 60dB window resulted in a higher noise floor, but 100dB and larger did not lower the noise floor, so I stuck with 80dB as a good parameter value. It might be useful to use other values if the FFT window width is changed or the noise in the data is different.

I’ve included the source code for the program, so that others can use it. It does require that SciPy be installed, in order to use the scipy.signal package.

#! /usr/bin/env python3

"""Sun Sep  4 21:40:28 PDT 2016 Kevin Karplus

Reads from stdin a white-space separated file 
whose first column is a timestamp (in seconds) and 
whose subsequent columns are floating-point data values.

May contain multiple traces, separated by blank lines.

Outputs a tab-separated file with two columns:
        the frequencies
        the Fourier transform

"""

from __future__ import print_function, division

import argparse
import sys
from math import sqrt
import numpy as np
try:
    from future_builtins import zip
except ImportError:     # either before Python2.6 or one of the Python 3.*
    try:
        from itertools import izip as zip
    except ImportError: # not an early Python, so must be Python 3.*
        pass

import scipy
import scipy.signal

class Trace:
    """One contiguous trace consisting of two 1D numpy arrays of the same length
        times:  timestamps in seconds
        values: arbitrary floats
      and sampling_freq: the sampling frequency in Hz
    """
    def __init__(self,times,values,sampling_freq=None):
        self.times=np.array(times)
        self.values=np.array(values)
        assert self.times.shape==self.values.shape
        if sampling_freq is None and len(times)>1:
            sampling_freq = (len(times)-1)/(times[-1]-times[0])
        self.sampling_freq=sampling_freq
    def __len__(self):
        return len(self.values)

def read_trace(file, column=2, sampling_freq=None, echo_comments_to=None):
    """Generator that yields traces from tab-separated rows of data.
    Each row contains a timestamp in the first column and any number of subsequent
    columns, one of which is selected to be the values for the trace.
    
    New traces are started whenever the timestamp in the first column decreases.
    
    If sampling_freq is None, the sampling_freq for the
    trace is deduced from the timestamps.
    
    Comments and blank lines are echoed to a file-like object,
    echo_comments_to, if it is not None.
    """
    times=[]    # time values (in seconds) from frst column
    values=[]   # values from the specified column
    
    for line in file:
        line=line.strip()
        if line.startswith('#') or len(line)==0:
            if echo_comments_to is not None:
                print(line, file=echo_comments_to)
            continue
        fields=line.split()
        if len(fields)>=column:
            time=float(fields[0])
            if times and time<times[-1]:
                yield Trace(times=times, values=values, sampling_freq=sampling_freq)
                times=[]
                values=[]
            times.append(time)
            values.append(float(fields[column-1]))
    if times:
        yield Trace(times=times, values=values, sampling_freq=sampling_freq)


def posint(opt):
    """returns int(opt) if that is positive,
            otherwise raises an argparse.ArgumentTypeError
    """
    try:
        x = int(opt)
    except:
        x=None
    if x is None or x<=0:
        raise argparse.ArgumentTypeError("{} is not a positive integer".format(opt))
    return x

def parse_options(argv):
    """Parse the options and return what argparse does:
        a structure whose fields are the possible options
    """
    parser = argparse.ArgumentParser( description= __doc__, formatter_class = argparse.ArgumentDefaultsHelpFormatter )
    parser.add_argument("--sampling_freq","-s", type=float,
            default=None,
            help="""Sampling frequency (in Hz). 
            If none specified, then estimate sampling frequency from the timestamps.
            """)
    parser.add_argument("--window", "-w", type=posint,
            default=(1<<16),
            help="""Max window size (in samples) for FFT.
            Longer traces will be split up into windows of this size
            """)
    parser.add_argument("--column" , "-c", type=posint, default=2,
           help="""What column should be Fourier transformed?""")
    parser.add_argument("--welch" , type=float, default=None,
           help="""Use Welch's method to produce averaged spectrum from windows. 
           Value is dB difference between main lobe and sidelobes for Dolph-Chebyshev window. 
           80 seems reasonable with 16-bit data (60 produces a higher noise floor, without noticeably narrowing the spikes).
           Note, sqrt is used to get amplitude spectrum, rather than power spectrum. """)
    options=parser.parse_args(argv[1:])
    return options


def main(argv):
    """parse the command line arguments and do FFTs
    """
    options = parse_options(argv)
    sampling_freq= options.sampling_freq

    # input file may contain separate time traces.
    # Each new trace stats when the time value is less than the previous time.
    
    for trace in read_trace(sys.stdin, column=options.column, 
                        sampling_freq=options.sampling_freq, 
                        echo_comments_to=sys.stdout):
        print("# using sampling frequency {:.6f} Hz for FFT of trace with {} samples".format(trace.sampling_freq,len(trace)))


        fft_len=64      # length of the fft to do
        while fft_len<len(trace) and fft_len<options.window:
            fft_len *= 2
        
        if options.welch is not None:
            welch_f,welch_spectrum = scipy.signal.welch(trace.values, trace.sampling_freq, nperseg=fft_len, scaling="spectrum", window=("chebwin",options.welch))
            print("")       # separate the traces
            for f,w in zip(welch_f,welch_spectrum):
                print("{0:.7f}\t{1:.6f}".format(f, sqrt(w)*(fft_len//2)))
        else:
            for start in range(0,len(trace),fft_len):
                window=trace.values[start:start+fft_len]

                # remove DC component, so that zero-padding makes sense
                # WARNING: This in-place change could introduce errors if
                # overlapping windows are allowed.
                dc = sum(window)/len(window)
                window -= dc

                fft = scipy.fftpack.fft(window, n=fft_len)
                fft[0] += dc

                print("")       # separate the traces
                print("# Window width {} = {:.3f}s".format(fft_len,fft_len/trace.sampling_freq))
                for i,f in enumerate(fft[0:fft_len//2]):
                    print("{0:.7f}\t{1:.6f}".format(i*trace.sampling_freq/fft_len, f))


if __name__ == "__main__" :
    sys.exit(main(sys.argv))
Next Page »

Create a free website or blog at WordPress.com.

%d bloggers like this: