How would I tell when a person has entered a dream from their EEG or EOG activity? I think there are changes that a researcher can see (like the EOG activity from the eyes looking around when in REM sleep), but can a computer detect this transition? Has anyone done this, or do you know of an algorithm that would work? Thank you.
I don’t know of any public algorithm for detection but I’m sure a good week of research and study could prove fruitful. I know this is Software but I’m curious: do you have a hardware solution in mind for comfortable detection? (As in, the sensors won’t be uncomfortable for the user)
It would interesting to see an EEG based detection of sleep. I think the EEG would suffer from noise generation unless the user was in a fixed position all night. (Maybe rig a headboard to hold a user’s head in place for a quick fix?).
1 Like
I just noticed the time stamp. How far have you come?
1 Like
@flxsosa Thanks! I was imagining, on the hardware side, that I would try an electrode at the top of the head, held on by an elastic cap of some kind, with the wire continuing straight so that rolling over wouldn’t pull on it too much.
I was hopeful that once the person was asleep, sleep paralysis would keep them from thrashing around too much. Some motion artefacts would be a given if the subject did move, but the algorithm would have to have some way of dealing with them I guess. I have not put any of this to test yet though and I do not know it would work in real life.
I have not come far with the software. I don’t have any experience with this kind of data processing and am not entirely sure where to start.
I think there are a few Zeos around still and that has an API. Perhaps that would be a good starting point?
Otherwise, Michael from LucidCode has done a bunch of opensrouce work on this, and he is very approachable. He wrote code for nearly every headset there is out there: http://lucidcode.com/
4 Likes
@Jay Thanks for responding … looks like the Zeos are our of stock on amazon but I could probably snag one from ebay or somewhere. Too bad the company is dead, as that would affect long term options.
Lucidcode is a really useful looking site. Never saw it before. Lucidscribe has plugins for just about everything (including the Zeo) and the halograph looks neat too. I’ll have to dig around there some more!
2 Likes
I’ve heard wet electrodes (using either saline solution or conductive paste) tend dry out over the length of time needed to do sleep or dream research. A number of options for dry/active electrodes are discussed in this thread on the OpenBCI forum. Florida Research Instruments dry electrodes seem to be pretty well respected, and the OpenBCI team is also prototyping 3D printed dry active electrodes which would be worth looking into.
The Zeo is still the best consumer product for REM sleep detection out there. If you think about getting a used one, I suggest paying a bit extra for the older Bedside version because there is a firmware for the docking station that also outputs raw data over a serial port. But if you really only need sleep stage detection, the newer Mobile (bluetooth) version works too.
The Zeo uses one EEG channel and an accelerometer, but the EEG channel also picks up eye movements if the headband is not placed too high. So there are three things to be analysed by the software.
I’ve tried before to do automated REM sleep detection with a single EEG channel using a ThinkGear toy EEG on a headband. But it never got reliable enough. The lucidscribe ThinkGear plugin (which uses only eye movements) works just as well, after a bit of tuning of the threshold setting. A good week of research and study may be enough to get a sleep stage detection as good as the one of the Zeo, but it won’t come close to the reliability of trained personnel of a sleep lab. 
If anybody wants to have a try, I could provide ZEO recordings of many nights, including raw data. My first step would be to imitate the algorithm of the Zeo, then to port it to another device.
But since your question seems to be more about hardware, here are a few thoughts on this. You could just get a Zeo and use that, like almost everybody does. It works, and not too bad. But I think it is time for a successor. Of the not yet freely available consumer devices, I think Aurora sleep mask would be best for sleep related applications. But since this isn’t available yet, the Melon headband might be an option. It’s pretty light and it’s surprisingly easy to forget that you are wearing it, given that your head happens to match one of the provided spacer sizes. The Melon has 2 EEG channels that could also be used to detect relevant eye movements and it has a 6-axis accelerometer.
Getting a bit more DIY, there is also the Halograph headband by Michael Paul, made for exactly this use case. But you’d have to be okay with wires. Different electrode placements might be useful, especially if you have 2 or 4 channels, so you could record from the forehead, including eye movements, and at the top, without eye movements.
Depending on how much wiring in/around the face is acceptable, you could of course also make it a bit more professional and record EEG, EOG and EMG. But I would focus on an easy to put on and comfortable to wear headband. OpenBCI would be in line for both alternatives.
There is also a headband-compatible version of the Brain-Duino, devided into three small PCBs instead of one big Arduino shield. But it’s not available as a finished device (yet?), only kits (ask me for a contact if you are interested).
A very promising project may be the Dream Writer device (“Traumschreiber”) that is currently developed by Kristoffer Appel and Johannes Leugeri at Osnabrück University. Kristoffer Appel has done dream communication research with a Zeo in the past. Their new device is mainly supposed to be a replacement for the Zeo for further research with study participants at home, keeping up the “sleep lab in a headband” image of the Zeo. There seems to be no information available on the web about this project. But I hope to get an idea of how the first prototype will look in a few weeks.
That’s the options that I have in mind for automated sleep stage detection. If wires are acceptable, you could use almost anything. If low reliability is also acceptable, you could really use anything. It depends mainly on what you think is acceptable to wear during sleep and what you want to write software for.
Please keep us updated! 
I would love to see anything new in this, no matter how DIY.
Looks like I didn’t read careful enough. So it is about the software. You were looking for a starting point. Have you found one?
I think the most sensible way to do it would be to first get the frequency ranges we are interested in through FFT, so it is easier to determine when higher frequencies (awake or REM) occur. Finding a good threshold is something that shoul be done with data from more than a few subjects. The same is true for eye movements. I think taking the data from an accelerometer into account would also be useful. The algorithm should signal that it has detected REM sleep only if all three data sources point to REM for more than a few minutes.
Would this be a good start?
Just ran across this REM state detection project on Hackaday,
https://hackaday.io/project/2733-lucid-dream-communicationresearch-link
He’s using this algorithm for state detection,
Thanks for this reference William. The algorithm looks like it would be super useful for OpenBCI sleep tracking or lucid dreaming experiments, and is spot on for the topic (though the challenge of implementation might be non-trivial). It’s a pity that the study authors didn’t include any code! Sounds like Jae Choi would probably provide his C implementation upon request.
It’s interesting that, according to the paper, EOG-detectable eye movements only occur during 27% of REM sleep. This was a surprise to me, and makes a reliable EEG algorithm all the more useful.
@steeph thanks for all the hardware info – your post could be turned into a small wiki on the topic.
My first step would be to imitate the algorithm of the Zeo, then to port it to another device.
Do you know what features the Zeo algorithm is using for REM detection?
Thank you for the links, @wjcroft! Very interesting.
@AdamM I don’t know. But I imagine the accelerometer comes in useful.
From Validation of an automated wireless system to monitor sleep in
healthy adults:
The electrophysiological signal includes contributions from the electroencephalogram (EEG), eye movements and the frontalis muscle.
The headband contains a 12-bit analog to digital converter and preprocessing unit which amplifies and filters the electrophysiological signal. The signal is captured at 128 samples per second and filtered within a second-order bandpass frequency of 2–47 Hz.
A microprocessor within the base station calculates the sleep stage from the signal in real time utilizing artificial neural network technology.
Optimization of the algorithm through training compensates for the lack of information below 2 Hz by the inclusion of available features in the determination of sleep stage. A sleep stage is assigned to each 2-s interval of recording; these are then smoothed using a 2-min moving average window, and a result is reported once every 30 s.
That’s all I got.
Hey there wjcroft, the hackaday article above is written by me; I’ll explain briefly on the current status of the project. If you need more information, feel free to ask me any questions!
In the beginning I tried to train ANN’s (artificial neural networks) using FFT data from EEG signals but it turned out to be very inaccurate and also difficult to implement. So as you saw in the article I have used a decision tree algorithm from SA Imtiaz et al and it worked quite well, although the accuracy wasn’t always that great. (I would like to upload diagrams/plots of the results that I got from the algorithm but apparently this forum doesn’t like me uploading images)
However the algorithm is still not accurate enough to detect REM stages. This issue is addressed in the study and they point out that adding EOG and EMG channels to the analysis greatly improves accuracy. So in the upcoming days I am going to implement an REM detection algorithm, and in conjunction with the algorithm I’ve implemented above I am sure it will work well. I’ll update my hackaday post when that is done.
EDIT: You can check my project log update for more info on this (I posted my results there):
1 Like
@SolarSunrise welcome to NeuroBB, and thanks for the first-hand update on this interesting project! Look forward following your progress.
Are you using the algorithm with default threshold values, or have you tweaked it at all? In the discussion at the end of Imtiaz et. al they mention that setting patient-specific threshold values can give more accurate results. This made me think that using some machine learning to set the alogrithm’s parameters might be a very effective combination. (Of course this would probably require manually coded training data from a specific individual).
In your previous ANN approach, what data were you using for training?
One other question: do you think it would be possible to modify firmware you’re developing for BioEXG to run on the OpenBCI, or does the PIC/Atmega not have the horsepower for it?
Three cheers for OSH + OSS!
1 Like
Hi Jae Choi (@SolarSunrise), thanks for that update.
re: your EOG additions to your algorithm, with that enhancement, sounds like you will have great accuracy. On your log link, you mention gold electrodes. Have you tried the small foam dot (1 inch) adhesive silver chloride snap-ons? May be more comfortable around facial sites. Leads here.
re: your BioEXG board. Can you mention your plans for that as far as further production or board sales? Would be interesting to see some photos of your complete setup there at bedtime. What kind of cap or headset arrangement you are using to keep everything in place. Will you have some sort of LED(s) near your forehead to flash signals? Etc.
You might well have one of the best engineered Lucid dream systems out there, I wonder if @Jay Mutzafi might comment, as he follows that field closely.
Best regards, William
Great to have you on the forum @SolarSunrise. Sorry about the trouble posting images — Discourse, the forum software we’re using, has an aggressive default spam protection system (based on time spent reading and a bunch of other factors) that restricts “new” users from some actions.
I have boosted your trust level, and you should be able to post images now.
For the recordings up to this point I have been using 3M red dot electrodes and applying them to Fpz-A2 for EEG REM detection and E1-A2, E2-A2 for EOG REM detection (check AASM manual for electrode placement). They are however pretty uncomfortable due to their large size, which is why I’ve resorted to using standard gold cup electrodes. Thanks for the link on those small foam electrodes, I might try those in the future.
In regards to production and board sales, I think using an ADS1299 chip for the application of inducing lucid dream is overkill, since technically only 3 channels (EEG and EOG) are used. Instead a “discrete” solution of using instrumentation amplifiers or a high resolution differential ADC may be more efficient. Actually my first design of the BioEXG board had an ADS1256, which worked quite well. For the stimulus, on the other hand, I’ve put together a device that vibrates when triggered by BioEXG. I’ll experiment more with lights and vibration later on when the REM detection, which has been very time consuming, is fully working.
However when designing my board I have not accounted for production as this really was just a personal project/experiment. Unless there is a huge demand for this device, my primary goal would be developing a solid algorithm for REM detection and sharing my implementation with others. This will especially be easier for the OpenBCI crowd as the same chip, the ADS1299, is used for my device.
Speaking of REM detection, in the past few days I’ve developed a primitive algorithm that extracts REM from two EOG channels. I will post an update in my Hackaday page if I have enough time. I am sure this will increase the accuracy significantly if used with the EEG algorithm.
1 Like
Although my implementation of the algorithm is virtually identical to the study, I used different filter settings (1-35hz instead of 1-50hz due to power line noise) which made the default threshold values listed in the study inapplicable for my program. So I plotted everything (SEFd values, RP, and AP) and visually selected the threshold values from there (check my update in the hackaday post on how it looks like).
ANN’s should be effective with this task but then an accurate hypnogram of my sleep recording would be required for training, which I do not have. Still, the accuracy at best would range from 60% to 80% depending on the night, hence why I am implementing an EOG REM detection algorithm to further boost the accuracy. Note that the most important thing here is to reduce the number of False Positives, as those will lead to false REM detection.
In my previous attempt, I just used raw FFT and fed it into the ANN, which didn’t work obviously. I am pretty sure I can get it to work, but the complexity of implementing it, especially since I don’t have a lot of time to spend on this, deterred me from going any further.
The code for this is actually not implemented for BioEXG but instead as a compact C++ library that runs on my computer (uses FFTW). The BioEXG board does no processing except transmitting raw data and calculating the impedance values of each electrodes. Therefore it shouldn’t be too hard to modify the library to work with OpenBCI (which will need CMSIS FFT for spectrum calculation) or for the computer program that receives data from OpenBCI. I don’t know of any fast FFT library (should be 512 point FFT) for AVR/PIC so I am not sure about those platforms.
Once the library is finished, which currently is not, I will write some comprehensive documentation so that you guys can take a look. And yes this whole project will be OSS + OSH when I am done with it. = )
1 Like
I’m sure EOG detection is the way to go, but just to satisfy my curiosity: according to the paper, with patient-specific thresholds the authors achieved an accuracy of 94%. Is the accuracy limit you mention based on your experimentation, or is there a theoretical reason I’m missing that means you couldn’t get higher EEG-only detection accuracy?
Interesting! This means it would probably be relatively easy to modify for use with OpenBCI data.
Will you be sending the results of the REM detection back to the BioEXG for some form of feedback or cues?
I suppose I should wait for the completed version and documentation before pestering you with too many questions…
1 Like
Is the accuracy limit you mention based on your experimentation, or is there a theoretical reason I’m missing that means you couldn’t get higher EEG-only detection accuracy?
Sorry I’ve should’ve been clearer with my explanation. The reason for the very low accuracy is that sometimes the sleep recordings I do are corrupted with quite a lot of noise and artifacts as I shuffle around a lot in my sleep. Also, I cannot calculate accurate threshold, only “eyeball” it, as I do not have a hypnogram for my sleep recording. These factors add up, resulting in mediocre but acceptable accuracy. I am sure the accuracy could approach the suggested 90% if the electrode wires are kept short, as to reduce artifacts, and the threshold values are set more precisely.
Will you be sending the results of the REM detection back to the BioEXG for some form of feedback or cues?
The BioEXG board has a feature so that if “O” is sent through the Bluetooth serial, one of its GPIO pin gets toggled, which is used to connect to a vibration motor I am testing as a stimulus. I may try flashing lights as well if the vibration stimulus does not work.
I suppose I should wait for the completed version and documentation before pestering you with too many questions…
Well actually your questions are sort of highlighting the key aspects of the program that I definitely should focus my attention on. There is a lot of things going on right now so your questions is sort of a refresher, which is very cool. I’ll try my best to finish the program as soon as possible. Thanks.
