Lab 13: FINAL PROJECT. Nathan Finney Partner: Henry Silva. Physics 111: Basic Semiconductor Circuits University of California, Berkeley 12/09/06

Transcription

1 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 (t A ). The alarm also compared the current run time (t R ) with t A 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.

2 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 ) 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.

3 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 V out 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

4 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 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 8- bit. 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 1 st 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

5 full REM cycle in the morning (We had ours set to 3600 seconds). The system performs two checks: Is the program run time (t R ) greater than the alarm time (t A ) 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 2 nd 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 90- minute 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 ). 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

6 (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.

7 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 ( Horowitz and Hill, The Art of Electronics, 2 nd ed., 1989, Cambridge University Press Rathus, Spencer A., Psychology in the New Millenium, 8 th ed., 2002, Thomson Learning Enc. Physics 111 BSC Lab Write Ups 4, 7, 8, 9, and 10.

8 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)

9 Fig. 3: Front Panel, REM Sleep Signal Fig. 4: Front Panel, NREM Sleep Signal

10 Fig. 3: Upper Left Hand Corner of Block Diagram Fig. 4 Upper Right Hand Corner of Block Diagram

11 Fig. 5: Lower Left Hand Corner of Block Diagram Fig. 6 Lower Right Hand Corner of Block Diagram

12 Fig. 7: Case 0 on the Block Diagram Fig. 8: Case 1 on the Block Diagram

13 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.

14 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

15 Fig. 15: REM Sleep identifier Fig. 16: Intermittent Save Feature Fig. 17: Alarm Clock Timing Functionality

16 Fig. 18: Boolean In REM and Final Hour? Logic Fig. 19: Boolean Not in REM and Final Hour? Logic Fig. 20: Alarm Logic

17 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

18