Lab 13: FINAL PROJECT Nathan Finney Partner: Henry Silva

Lab 13: FINAL PROJECT
Nathan Finney
Partner: Henry Silva
Physics 111: Basic Semiconductor Circuits
University of California, Berkeley
12/09/06
Abstract
A Rapid Eye Movement (REM) Sleep Detector and Alarm Clock was designed,
built/programmed, and tested. The signal for the analog component of the detector/alarm
was collected using an Infrared Light Emitting Diode (IR LED) pointed at the right
eyelid, which reflected the light into a phototransistor at different amplitudes due to
changing orientations of the eyelid/eyelashes. The signal was then treated so that it could
input safely into the microphone jack on a laptop’s soundcard. A LabVIEW program then
called the data from the soundcard, displayed it, decided whether or not the amplitude of
a given point was above some critical value, which would deem it an instance of REM
sleep, then it counted all the instances of REM sleep for a given interval (10-seconds).
The number of instances per sample interval was then saved to an array, which would
later all be saved into a .txt file. The program had a functional alarm that could be set to
go off after a given amount of time (tA). The alarm also compared the current run time
(tR) with tA and if their difference was less than or equal to 1 hour and the person sleeping
had been out of REM sleep for more than a minute then the alarm would go off. This
logic intended to keep the sleeping person from being woken up during REM sleep. The
data logged in the early morning hours of Friday (12/8/06) shows cyclic behavior (Fig.
23), with peak densities of activity occurring in approximately 90-minute intervals.
Functionally the circuit and the program worked perfectly, though more research must be
done to fine tune the input values that determine the behavior of the alarm clock.
Introduction
The main motivation for the construction of the REM sleep detector and alarm
clock was to check whether or not REM sleep behavior discussed in many introductory
psychology textbooks matched our own sleep behavior, and to see if there was an ideal
time to wake up in relation with these cycles. To give some background to this behavior,
there is a brief summary of a description of sleep cycle behavior in humans from
Psychology in the New Millennium by Spencer A. Rathus (pages 124-126) in the Theory
section of this write up (page 4). From that information we tested the following claims:
(1) REM sleep occurs on average at 90-minute intervals, with each cycle getting longer
and more intense as the night wears on, (2) A person woken up during REM sleep feels
as though they haven’t slept at all, therefore a person who wakes up close to their desired
wake time (but not while they are in REM sleep) will feel refreshed.
We found that the first claim turned out to be true, that on average I go through
90-minute cycles (varies a little throughout the night), and the activity seems to increase
as the night wears on. The second claim was neither refuted nor verified. Our alarm
actually ended up going off during my last REM cycle (Due to a false assumption on our
part, that REM sleep will go no more than a minute without showing activity). I actually
felt totally refreshed. It isn’t clear whether I was feeling that way because I got to wake
up to my own recorded voice telling me to wake up, thus signifying that our project was
working, or that I was actually waking up at an ideal point in my sleep cycle.
Though performing the actual experiment pertaining to REM sleep was our goal
for the project, we spent the majority of our time working on the detector and program.
The process of designing and building the circuit as well as troubleshooting the
LabVIEW program are pretty well documented in the attached Photocopy of my Lab
Notebook (PLN). Basically we approached the design process from two ends. The circuit
and the LabVIEW program were developed concurrently, and occasionally we used the
DAQ we have in lab to make sure that the program was behaving essentially as it should.
After a while the LabVIEW program was developed entirely using the built-in
microphone inside the laptop as an input. The fact that the program does not distinguish
between sounds coming in through the built-in microphone and a signal coming into the
microphone jack worked to our advantage, because even though the circuit was not ready
to input signals into the computer safely, the program could still be developed.
The major obstacle in the design of the goggles was finding the best orientation
for the IR LED and the phototransistor (see Fig. 1 for the final design of the goggles).
The circuit was tricky, but simple to develop. It involved using a high pass filter and
amplifier to get the maximum allowable AC signal strength for the microphone jack, then
introducing a “protection stage,” which would ensure that the current and voltages
applied to the jack wouldn’t be able to go any further than those allowable limits for the
sound card. The goal was for the circuit to be portable so that we could take it home and
test it out. A more in depth description of the analog component of our project is given in
the Circuit section of this write-up. All of the work thereafter was put towards getting
our LabVIEW program to work. Please see the Program section of this write up for an in
depth description of the LabVIEW program, whose major obstacle ended up being
associated with the way the computer calls data from the sound card, and how that effects
our running the program for extended periods of time.
Circuit
As shown in Fig.’s 1 and 2 the analog component of our project is extremely
simple in its final form. By putting two 9V batteries in series (which were in parallel with
two more 9V batteries in series), the voltages V+ and V- were produced. The Goggle
stage produces a fluctuating signal (with a DC offset) that is a measure of how much the
eyes are moving and flickering underneath the eyelids. The signal is then amplified and
put through a high pass filter with a very low cutoff frequency to get rid of the DC offset.
Next the signal is put through a protection stage to ensure that the signal going into the
laptop will be between ±600mV. The acceptable range for most laptops is ±400mV
(hacker-technology.com), so we decided that since our signal seemed to peak at ±200mV,
a ±600mV safety net was suitable for saving the laptop form frying. Also, the protection
stage was made to cut out the DC output coming from the laptop’s microphone jack that
would normally power a microphone. The output impedance of the protection stage was
made to be lower than the input impedance of the jack, which turns out to have its high
pass filter within.
R1 and R2 in the ‘Goggle stage’ are only there to limit the current coming
through the IR LED and the phototransistor so that they don’t get too hot or stop
working. Both the IR LED and the phototransistor are nonlinear circuit elements whose
current varies with applied voltage/electromagnetic stimulus. In this sense the amplifier
in the ‘Amplifier and High Pass Filter stage’ works by trying to match the current
produced by the phototransistor (current source) such that the two currents will add up to
zero at the negative terminal on the op-amp, which is at virtual ground. This voltage drop
across R3 is what produces the gain of the amplifier. The amplifier in combination with
R2 and the phototransistor is optimized because the current selected by R2 does not
require the current coming out of the Vout terminal on the op-amp to be greater than
20mA. The signal is then filtered to cut out DC by having 1/(2π*C1*R4) ≈ 0.1Hz. Next
the signal enters the ‘Protection stage’. The signal is put through a unity gain amplifier
(voltage follower), which limits the current to 20mA and isolates the signal from its
previous stage. The signal is then passed over the diodes. If the signal is approaching
±600mV then one of the diodes will behave like a short (this is due to the asymptotic
behavior of the diodes at ±600mV, which allow for ±large currents to pass though them
at these voltage limits). Next the signal goes through another DC filter, which is in place
to filter out the DC signal coming from the laptop. Finally the signal goes through
another unity gain amplifier (voltage follower) to isolate the capacitor in our high-pass
filter from the capacitor inside the microphone jack (See PLN page 10), and to reduce the
output impedance of our circuit.
The signal then goes into the computer’s soundcard via the microphone jack
where it is collected as if it was an analog audio signal, digitized, and then sent to
LabVIEW.
Program
The program has four main functions: (1) To read and analyze the signal
originating from rapid eye movement which is eventually fed into the computer via the
soundcard, (2) To wake the user up after an elapsed time that the user has the freedom to
choose, and (3) To wake the user up if they are within a certain interval from their chosen
wake-up time, and they have left REM sleep, and (4) To save the activity of the night into
a list that can be graphed in excel. The block diagram is broken into stages that can easily
be viewed in the Figures section. Unfortunately the entire block diagram is too large to
be put in this report as one figure so it is split into 4 figures (Fig.’s 3 - 6) each with
enough information to see how they relate. Also the three major case structures are
shown in Fig’s 7 – 9. Hopefully this will provide enough information for the reader to
troubleshoot the explanation of the program.
Fig. 10 shows the input stage from the soundcard that was hacked from the
example program “Sound Card Simple Spectrum Analyzer.vi”. In our program we left SI
CONFIG and its inputs outside the large while-loop, which encapsulates the rest of the
program, and the SI START .vi inside case1 in the large case structure (See Fig. 8). Both
are left out of the Data collecting for-loop shown in Fig.’s 11 and 12 because they only
need to be called once (we ran into some problems when we tried to keep reinitializing
them with each data collecting loop, because there are only 16 ‘slots’ in the soundcard
that can be initialized at once, and with each data collecting loop a new ‘slot’ would be
initialized). We set the Buffer control to 24576 for our final test, because it became
important later on when we were building our data array that there was a large difference
between the allowable number of samples in a given data collecting loop, and the amount
of time we were collecting data for. On the first night we had the buffer size set to 100,
and even when we were only using two-second data collecting loops the program still
crashed occasionally. We had the sound format set to “mono” since there was only one
signal coming in. We set the sample rate to the lowest quality (8000), and the sound to 8bit.
The for-loop shown in Fig.’s 11 and 12 takes the incoming 1D array of amplitude
levels form the soundcard adds them to another array for a given amount of time
(controlled by the user). We looped the SI READ for 10 seconds in our final version
(This actually averaged to be something more like 14 seconds due to a lag in the program
somewhere).
Fig. 13 shows how we filtered most of the 60Hz noise (which was much less
prevalent in a dark room), and cut out the strange appearance of a DC offset (which was
only present when we used the sound card to read the data) using two consecutive bandpass Chebyshev filters.
Fig. 14 shows how we analyzed the filtered data to see how many instances of the
amplitude were over a given value of V(REM) = 7.5 for a given sampling interval. The
number of hits for each sample interval was then stored in an array. In the true case the
program adds 1 to the number of hits above V(REM), for the false case it simply feeds
the number of hits above V(REM) back into the shift register to await the next point.
Fig. 15 shows how the program determines if the user is undergoing REM sleep.
If the number of points over 7.5 is larger than 200, then there has been a recent REM
occurrence. Figure 16 shows how using a Boolean control the user can chose to save the
data at any point. The program will continue running after the data is saved, and once the
alarm goes off the data from the 1st save point until the end of the night will be saved in
another file.
Fig. 17 shows the alarm clock timing functionality, where the user sets the total
number of seconds that they want to sleep, as well as something called the REM
Boundary, which is the amount of time the user thinks they should have to complete a
full REM cycle in the morning (We had ours set to 3600 seconds). The system performs
two checks: Is the program run time (tR) greater than the alarm time (tA) and is the
difference between the two less than the REM boundary time? If the first condition is
satisfied, then the alarm will go off, thus waking the user up in time for their exams. If
the first condition is not satisfied we enter the smart alarm phase. If there has been recent
REM activity then the case shown in Fig. 18 is true, the alarm will not go off, and 1 will
be added to a shift register (this count we will call the ‘in-REM’ count). If the case is
false, and the 2nd condition is satisfied (Fig. 19), and the ‘in-REM’ count is greater than 1,
then the alarm will go off. The ‘in-REM’ count ensures that the smart alarm logic won’t
be initialized unless there was an actual REM cycle happening in the final hour.
Fig. 20 shows the alarm, which goes off as the while-loop controlling the
repetition of 10-second data cycles stops and the data is saved. The alarm can be used to
play any .wav file, be it music, or your own recorded voice.
Theory
Rapid Eye Movement (REM) sleep is a universal behavior in humans,
characterized by the visible movement of the eyes underneath closed eyelids. There are
four stages of sleep (stages 2 – 5) that are characterized as non-REM (NREM) sleep.
These stages are uniquely determined by frequencies of brain waves corresponding to
each cycle. On average, stage 1 (REM) sleep happens four to five times a night at 90minute intervals if a person sleeps for eight hours (Fig. 21). The brainwave patterns
associated with REM sleep are very similar to the brainwaves of a waking person, and
often when awakened during REM sleep, the person sleeping will report that they had
been dreaming. If a person is woken up from stage 1 sleep, they will also sometimes
report that they feel as though they haven’t slept at all. It is hypothesized that people
deprived of REM sleep learn more slowly and forget what they learned more rapidly, and
that they will later catch up on their total REM sleep in a given week by having longer
lasting intervals of REM sleep during the night. (Rathus, pp. 124 – 126).
Experiment
When our goggles, circuit, and program were all working together to form the
REM Sleep Detector and Alarm Clock we took it for a test run. The first night we tried it
we had trouble with the program’s buffer, which was set at too low of a level, thus
causing some I/O disturbance between the sound card and our program. Henry ended up
staying up to reset the program every time it crashed, while I was asleep wearing the
goggles. Though that particular setup was impractical and couldn’t possibly include a
functional alarm clock, we did manage to capture a screen shot of an REM sleep signal
(Fig. 3). When compared to the extremely flat signals captured from the second night
(Fig. 4), it is obvious that there was definitely eyeball activity during the night. The
histograms in Fig.’s 22 & 23 show how the activity was dispersed. The behavior was
cyclic with an approximate spacing of about 90 minutes between each cycle. There are
many instances where there seems to be some activity between the periods of increased
activity where we see large fluctuations. These we probably would not characterize as
REM sleep because they are so short lived. More likely they represent me shifting in the
night or waking up briefly. Note in Fig. 23 how the interval of the activity cycles
increases as the night goes on, and so does the average amplitude. On the Second trial
(Fig. 4) the program ran all night and woke me up during my last REM cycle. We did not
mean for it to do that. The reason it behaved that way was because we set the post-REM
wait-time to only 1 minute, when really it should have been more like 10 minutes. I
showed a minute of non-activity and there was less than an hour left until I was supposed
to wake up, so the computer played the recorded .wav file. Thus in the second night of
testing we accidentally tested the opposite of claim 2 listed in the Introduction: we
tested whether I would feel bad when woken up during my last cycle of REM sleep.
“Wake up bitch!” my own voice exclaimed (with reverb for dramatic effect) as
the program finished up and saved our data to a .txt file. I felt extremely refreshed, and
was very happy to take the goggles off (the large spike on Fig. 23 is from when I woke up
to adjust the goggles, which were digging into my face). Later in the day however I felt
extremely sluggish, possibly because I hadn’t had enough REM cycles the night before?
Conclusions
We were successful in building a working apparatus that can log data about a
user’s REM sleep, and wake them up based off the information it collects and certain
input values given to it by the user. Both the analog and the programming component of
this project required that we use a variety of skills and knowledge that we learned in
Physics 111: Basic Semiconductor Circuits at UC Berkeley, and in the end we got to
actually run a scientific experiment (one that needs to be revised and repeated)
concerning the science of REM sleep in humans.
I would call our results concerning claim 2 from the Introduction inconclusive,
because the nature of this kind of study requires both a more rigorous control of the
variables that can affect REM sleep (i.e. the comfort of the goggles, better defined control
values within the program, etc.), as well as a large sample size of different people as test
subjects. Something that they teach in every intro level psychology class is that in order
to say anything about people in general, you need to employ statistical analysis with a
proper sample size that represents the group that you are trying to study in a non-biased
manner. In my experience on Friday morning, there is no way to tell whether I felt good
because I had had good sleep, or that maybe I felt good because I was happy that our
program and circuit worked all night, the alarm worked, and the precious data was saved.
That just adds to the inconclusiveness. I think that with many trials however, Henry and I
could figure out exactly the right calibration for the program to wake me up at various
points in my late morning sleep cycles, and we could test my personal response to waking
up at these times.
Further developments could be made to make the REM Sleep Detector/Alarm
Clock marketable to Sky Mall Catalogue: (1) Dumb down the user interface, and make
calibration automated, (2) Incase everything in stainless steel, (3) Shorten the name to
something like “AutoREM2010,” (4) Include some zany extra feature, like a honeybee
mind controller and honey filter.
Acknowledgements
I would like to thank my partner Henry for doing basically all of the LabVIEW
programming and making sure I new what was happening from his end, and especially
for letting me be the sleep subject while he stayed up late playing Mario Brothers. Thanks
to Professor Holzapfel for making himself available to us both in office hours and in the
extra hours that he kept lab open. Thanks to the G.S.I.’s for helping us alllll semester
long. Thanks to my dad for lending us his breadboard and for supporting the project!
References
hacker-technology.com (http://www.hacker-technology.com/4361/30004.html)
Horowitz and Hill, The Art of Electronics, 2nd ed., 1989, Cambridge University Press
Rathus, Spencer A., Psychology in the New Millenium, 8th ed., 2002, Thomson Learning
Enc.
Physics 111 BSC Lab Write Ups 4, 7, 8, 9, and 10.
Figures
Fig. 1: Goggle Diagram
Fig. 2: Circuit/Block Diagram
(R1=1.2k, R2=1k, R3=10k, R4=R5=1.6M, C1=C2=0.1µF, V+ = +9V, V- =-9V)
Fig. 3: Front Panel, REM Sleep Signal
Fig. 4: Front Panel, NREM Sleep Signal
Fig. 3: Upper Left Hand Corner of Block Diagram
Fig. 4 Upper Right Hand Corner of Block Diagram
Fig. 5: Lower Left Hand Corner of Block Diagram
Fig. 6 Lower Right Hand Corner of Block Diagram
Fig. 7: Case 0 on the Block Diagram
Fig. 8: Case 1 on the Block Diagram
Fig. 9: Case 2 on the Block Diagram
Fig. 10: Soundcard Sub-VI’s used to configure and read the soundcard
Fig. 11: Build Data Array (for a user specified amount of time) –Top Half.
Fig. 12: Build Data Array (for a user specified amount of time) –Bottom Half.
Fig. 13: Filtering and Displaying the Filtered Signal
Fig. 14: V(REM) Counter
Fig. 15: REM Sleep identifier
Fig. 16: Intermittent Save Feature
Fig. 17: Alarm Clock Timing Functionality
Fig. 18: Boolean ‘In REM’ and Final Hour? Logic
Fig. 19: Boolean ‘Not in REM’ and Final Hour? Logic
Fig. 20: Alarm Logic
Fig. 21: Basic Sleep Cycle Pattern (Rathus, p. 125)
Fig 22: Eye Activity from Morning Hours of Thursday
Fig. 23: Eye Activity from Morning hours of Friday