This app is in the alpha stage, and currently there is very little documentation beyond the discussions on the OpenEEG mailing list, which I have pasted in below. However, I thought I would give it a page so that people know about its existence. It currently reads data from a file or from the serial port in one of several formats (including both of the modularEEG formats), and it allows display of the analysis as bars. The configuration is very flexible, using Fiview-style filter-specs (using fidlib internally) to determine the analysis driving the bar display. The analysis method gives very fast response, and is documented HERE. Several screens of bars may be set up and switched between. There is some testing code in there for audio feedback too, but this needs a lot more work. Development has stalled on this project for the moment, as I concentrate on other things.
I've just got the latest release up here without all the previous versions.
eegmir-release.zip (391K)Date: Sun, 9 Feb 2003 14:13:22 +0000 To: openeeg-list@lists.sourceforge.net Subject: Prototype real-time app release 0.1.1 Joe Street has been encouraging me to get a move on with writing some real-time code, and I've made some progress. I have taken the approach of creating a prototype rather than trying to do everything 100% correctly first time. [...] I have a snapshot up here: http://uazu.net/temp/eegmir-release.zip I'm using a ZIP file in order to do joint Linux/Windows releases. Text files appear in their natural UNIX format, but are duplicated in Windows CRLF format with a .txt extension for the benefit of Windows users. A Windows binary is included, as is the SDL.DLL file. So, Windows users have it very easy and just need to run the EXE. Linux users may or may not have to rebuild from source, but in any case they *will* need to install SDL. In this prototype, you start on page F1 (an error logging screen), and you switch between pages using the function keys. You can exit the app using ESCAPE. Feel free to resize it -- everything adjusts. Everything is controlled from the "eegmir.cfg" file. At the moment there is only a bar-display coded up. However, it is very flexible, as it is specified in the config file using Fiview filter descriptions. So, you can design your filters with Fiview, and then build an EEG bar-display from them. The filtering is done with my heterodyne technique (which gives continuous outputs rather than oscillating ones), so you just need to select the bar centre-frequency and a low-pass filter that describes the required response around that centre frequency. So the line: filter 10, LpBu4/=2; specifies a filter between 8Hz and 12Hz, since the low-pass filter width is 2Hz. (The = flag is my new notation for the old fiview -a auto-adjust option -- basically, it just makes sure the filter gives its 50% response point at exactly 2Hz; I need to do a fiview release with these changes in, but not right now ...). The output of that filter drives the spots on the display, and the signal is passed through a further smoothing filter to drive the bars themselves. This is another low-pass filter. I reckon LpBe2 filters are good for this, but you can use any filter you wish, or even 'x 1' for no filter at all. You can define different bar charts in the .cfg file for each of the F-keys from F2 to F10 if you wish, and switch between them. The current bar-chart display is just something I knocked up quickly to test it. I should really try to make a nice Mind-Mirror emulation, or experiment with exponential or linear sets. Anyway, if anyone designs any nice bar-charts, they just need to post the config files. Incidentally, I used Jack Spaar's code for doing serial input on Windows. I did try to use the OpenEEGLib code, but it was going to be too much work to strip it down to what I actually needed (as well as converting C++ -> C), so I took the easy option. As I have taken the shortest route, vast chunks of the code may need to be rewritten or reorganized at a later stage. For example, all the planning that Dave, Andreas, etc have been putting in to the OpenEEGLib is to avoid this kind of massive refactoring. Still, in the interests of testing ideas and getting something working in the form of a prototype, I think this is okay. Also, I have to say that SDL is great -- it "just works". After testing on Linux, I just needed to fix one typo I introduced into the Win serial code, and it built and ran fine right away. (I tested on Win98SE as that's all I have here). I've also set up scripts now using the MinGW cross-compiler so that I can build the complete release ZIP (including Windows executables) just with one command from Linux. This means I can make releases fairly often. Right now, I want to put in the features that Joe is after, plus any other ideas that come to me -- that is the main priority. However, I also wanted to get the code and executables out there so that other people can play around with it if they want to. Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Wed, 12 Feb 2003 00:59:33 +0000 To: openeeg-list@lists.sourceforge.net Subject: EEGMIR 0.1.2 I've put up version 0.1.2: http://uazu.net/temp/eegmir-release.zip I've fixed most of the bugs people mentioned (but not the 1-channel crashing bug), and set up a nice Mind Mirror emulation on F2, along with 'file' input (as an alternative to serial input). Also Jim Meissner format files can be read in (and Jim-M could probably even run it on his old hardware). The config file format has changed a little, so any old config files probably won't work without modifications. See the new config file for examples of how to set up running from a file. There are now also settings you can change on the bar display page. They work very similarly to BWView -- i.e. press a letter to select which one you want to change, and then use digits to access preset values, or +/- keys to change in smaller steps. '=' is the same as '+'. The bar display only has two settings at the moment, but other displays are likely to have a lot more. Sometime I should document all this, but there seems little point when it's all changing so quick. Also, (Joe) the signal display colours have now been corrected so that the fill-in colour is not too bright. Actually, I copied the wrong colour value from BWView, so that explains why it looked wrong. Next job is a display to show how much jitter we are getting on the incoming data, and then some audio output code. (The jitter information is necessary in order to see how much it is necessary to delay the data feeding to the audio code in order to have a clean output -- although I could try it both ways). Running the Windows version under emulation in Win4Lin, I can get it to drop dead with an error whilst running -- seemingly because it overloads. This could be because of the emulation, though. However, if anyone has problems like this, let me know. I may need to think more about optimising things and prioritising the threads if we start running into trouble. Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Tue, 18 Feb 2003 01:58:50 +0000 To: openeeg-list@lists.sourceforge.net Subject: EEGMIR 0.1.4 release The latest version of my prototype biofeedback app for Windows and Linux is available here: http://uazu.net/temp/eegmir-release.zip Major changes since the previous version include: - Jitter and sampling-rate measurement screen on F12 (by default, see config file) - Changes to avoid trouble with the event queue overflowing - 'jm2' and 'jm4' formats are now called 'jim-m', with 'chan' values of 2 and 4 The jitter measurement screen on F12 shows two lines wrapping around in columns -- one is the estimated actual time that the sample was generated, and the second is the time it actually arrived. The area between these two lines is filled in yellow. If there is a delay somewhere in the system, then a bunch of samples arrives late, which looks like a step on the display. If sync is lost, then you get red lines as well. At the top is reported the measured sample rate (i.e. the sample rate measured using the computer's clock) along with the theoretical rate you put in the config file, then the maximum and average jitter in ms. (I typically get 257.14Hz for the measured sampling rate from my modularEEG.) The whole display will be nonsense for the first few seconds as the internal buffers fill up with good data from the EEG device. After that point it should look like a load of little steps, the smaller the steps the better. (Note: you need to press F12 to get it to redraw). Running on Linux on a dodgy Celeron-900 box and using the irqtune setup that Andreas suggested a long time back, I get 9ms average jitter (25ms max) whilst running the Mind Mirror screen. If I drag the windows around (filled drag, which blocks the interrupts with my chipset on this version of X-Windows), I start getting red lines. Running on Windows (Win98SE), though, the result is quite spectacular. With the Mind Mirror display running, I get 1ms average jitter (11ms max). The yellow line is barely visible. There has to be something very right going on here. Maybe the way SDL hooks into Windows gives it some advantages it doesn't get on Linux. By doing random things on Windows I could get some big steps to appear (e.g. 100-200ms delays), but I couldn't get it to lose sync. Incidentally, I've made full use of the packet counter in the modularEEG format now, and it will fill in error samples for any that are missing. This means that the timing display is not in any way upset by packet or sync loss. For the next version, I'm considering trying the serial port code in the audio handler, on the basis that this is likely to be called with a higher priority. This may get around some of the 100-200ms delays on Windows, although we'd lose the 1ms jitter level. It is worth a try anyway. The event queue overflows were reported by Jack Spaar on his very fast machine, which seem to make no sense to me, but I had also seen them running on Win4Lin (Windows emulated on top of Linux). So, I've put some code in to handle these more nicely. You'll see messages on F1 if a TICK event ever has to be dropped. (Also, remember that you can page up and down the event history on F1 using PageUp/PageDn/etc) That's it for now -- Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Fri, 28 Feb 2003 21:40:21 +0000 To: openeeg-list@lists.sourceforge.net Subject: EEGMIR 0.1.5 release The latest version of my prototype biofeedback app for Windows and Linux is available here: http://uazu.net/eegmir/eegmir-release.zip There is nothing too amazing on the outside for people who are hoping for new features, but I've sorted out a lot of stuff on the inside. This is still very much a prototype, and you'll probably have to fiddle with some config values to tune it to your system. - Audio output is now working, with some FM output to prove it works - Serial reads can now be done either in their own thread or from the audio thread. I had to do a lot of head-scratching to figure out how to get the three clocks synchronized (computer clock, EEG device clock, and audio sample clock) especially considering the only available cross-checks between these clocks may be inaccurate (e.g. processing delays may mean we handle an incoming packet late, or an outgoing audio block late), but this is sorted now, I think, and any clock drift is handled smoothly. Things you may want to tune in the config file: [audio] buf 1024; rate 44100; The 'buf' setting should be a power of two and gives the audio block size in samples. 1024 is 1024/44100*1000 == 23.2ms blocks. 512 (12ms) doesn't quite work on my Linux machine. On Windows (W98SE) I had to up it to 2048 to get smooth audio output. [win-dev] audio-sync; port COM1 57600; fmt modEEG; rate 256; chan 2; You may want to try it with 'audio-sync' either present or commented out. Without it, serial reads are done from their own thread. With it, they are done along with the audio processing. In theory audio should get higher priority than anything else, but it doesn't look like that's always the case. Maybe it's worth trying both ways. Probably without is better on Windows. [F2] bands; fps 20; ... You might want to change the FPS (frames per second) of the displays if the load is too much. [F11] audio; test-fmsig 50ms 1000+500/100; This is the audio page (on F11). At the moment there is only some testing code generating FM audio output. This uses EEG channels 1 and 2 to drive sine-wave oscillators on the left and right stereo outputs. The centre frequency is 1000Hz here, with frequencies ranging between 1000-500 and 1000+500 (i.e. 500Hz to 1500Hz). The volume level here is 100 (meaning 100%). The ms figure tells the audio code how far back in time to look for the data samples to output. You can set this to 0ms if you like, but then every single little delay in the system will show up as disruption in your FM audio output. The idea is to find some delay value that the jitter rarely exceeds (see F12 screen for jitter values). If you're using a 2048-sample audio buffer and 'audio-sync' set, then you'd need to set it to 100ms or so. Probably it would be a good idea to get rid of audio-sync, though, in that case. The FM code does interpolation between the incoming samples, so it should be pretty smooth. However, listening to this for too long was giving me a headache and I was glad to turn it off -- you can comment it out in the config file. However, it does prove that it is working. I hope to add other audio options and more flexibility in future in the audio output, for example a hb2.mp3 style output, or maybe a simple amplitude-modulated noise output. I don't know if this FM output accurately reproduces the result Joe Street has achieved through hardware -- perhaps he can tell me if it needs correcting in any way. So, no big new features, but I've sorted a few things out. Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Tue, 11 Mar 2003 22:59:22 +0000 I've put a new release up on my site, with only minor changes: http://uazu.net/eegmir/ The main difference is that there is a new option in the [win-dev] section, called 'rawdump', which is commented out at the moment. If you uncomment it, all the data received whilst the program is running will be written to a file called 'dump.raw'. You can replay it again using the 'file' options from before. Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Tue, 15 Apr 2003 17:42:28 +0100 To: openeeg-list@lists.sourceforge.net Subject: Re: [Openeeg-list] hi amyl wrote: > thanks for the advice! I'm really impressed with your progams: EEGMIR, > FIVIEW, BWVIEW. I've been interested in using the modular EEG as an EOG and > pipeing realtime data through fiview using this filter: > fiview 256 -i LpBe8/25, LpBu8/25 > And displaying it in eegmir (which I must add is really impressive > especially with the sounds); is this possible, and how do you pipe data > through fiview? Sorry for the delay in replying -- I've been away for a few days, and now I'm down with 'flu, which isn't helping. Fiview is just for designing the filters. If you actually want to put data through the filters, you'd need to compile the example code generated (i.e. write your own program). However, eegmir uses fiview filters internally, so you can use your filters there. You'll need to look at the eegmir.cfg file. For example, you could create a special bar display that shows the input signal passed through your filters. For example, using something like this: filter 0, LpBe8/25; Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Thu, 24 Apr 2003 10:19:39 +0100 Subject: EEGMIR and BWView updates for new firmware I've released new versions of EEGMIR and BWView on my website: http://uazu.net/eegmir/ http://uazu.net/bwview/ The updates are just to support the new modularEEG packet format, as output by the firmware that Andreas plans to release shortly. For EEGMIR, the format-handler "modEEG" now expects the new packet format -- "modEEGold" is available for handling the old format. For BWView, the format-handler "mod/<rate>" now expects the new packet format -- "mod0/<rate>" is provided to handle old-style files. I've tested these with my own modularEEG device, and everything seems to be working fine, but if anyone else has problems (once Andreas has released the firmware), please let me know. Jim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To: openeeg-list@lists.sourceforge.net Subject: [Openeeg-list] Testing viability of OpenEEG server ideas with EEGMIR Date: Tue Dec 30 01:19:42 2003 I know I am supposed to be studying, but I've made some changes to EEGMIR just to test the idea of passing data over TCP/IP. These only work on Linux for the moment (I'm not set up for Windows cross- compilation and testing on this laptop yet, and my previous main machine died): http://uazu.net/eegmir/ I've added client code to EEGMIR which connects to an "OpenEEG server" as specified in Rudi's draft, and displays the resulting data stream just the same as it does any other EEG data stream. To set this up, just put "server localhost;" in the [unix-dev] section of the config file (instead of all the serial settings or whatever). See the *.cfg files provided for examples. Connecting to other machines than localhost should also work, but I haven't tested that. I've also added some really minimal "OpenEEG server" code to EEGMIR to test the other side. If you start it as "eegmir -S", it runs as a server without the GUI, using "eegmir-server.cfg" as its config file. All the display-related stuff is ignored in the config file, but the device section is used to set up a device as normal (either a file or a serial port). The data from this device is then made available to a client connecting on port 8336 via EDF as spec'd in the draft. When I say the server is minimal, I mean it -- it only handles one client for one session, and it only understands two of the commands Rudi put in the draft, i.e. "GetEDFHeader" and "SendSamples". It also fakes most of the EDF info instead of filling in proper values. This is all that is needed to test the connection, though. I'm sending through the error information in channel 0 of the EDF file. Because error information only requires one bit per sample (I'm using bit 0), I've called the channel 'OpenEEG flags', allowing the possibility of using the other bits for other things. This is all open for discussion and change, though -- I set this up just for testing. Unfortunately I don't have my modularEEG device with me right now due to moving, but I have tested reading data from a file with the server (eegmir -S), and sending it via TCP/IP to the client (eegmir) and displaying it there, and it works well. The jitter is low. It would be much more interesting to see how it copes when the server is reading live data from the serial port, though. Perhaps someone using Linux can test it. (You just need to edit eegmir-server.cfg to comment out the existing [unix-dev] section and uncomment a section that reads data from the serial port instead, with whichever protocol (P2/P3) you are using). It would be interesting to compare the F12 displays to get an idea of how much (if any) jitters and delays are added due to the server->client connection (i.e. try it with EEGMIR as it is normally configured reading from the serial port, then try it with the server reading the serial port, and the GUI side of EEGMIR reading from the server). But anyway -- things seem promising so far. Jim
These pages and files, including applets and artwork,
are Copyright (c) 1997-2019 Jim Peters
unless otherwise stated. Please contact
me if you'd like to use anything not explicitly released, or if
you have something interesting to discuss.