Introduction

This is not exactly a tutorial. It was not written from an objective point of view. It perhaps could be included in the category of propaganda. It tries to encourage you to encode your data in EDF+. I am certain that most clinical neurophysiologists can understand, and begin to use EDF and EDF+ in some days. If they know some programming language (even not deeply) they can read or write EDF files in less than a week. Even more, if they do not know a programming language, trying to decode an EDF+ file can be a challenge to motivate the learning of a language by programming a non-trivial but simple task. If, even considering this warning, you feel that I exceeded a reasonable limit in my enthusiasm for EDF/EDF+, please let me know and I will try to correct this point in future editions.

EDF (European Data Format) is an open format designed to interchange data in Clinical Neurophysiology. Although storing data in EDF format is a possibility in many modern EEG devices, it was designed to interchange sleep recordings. These recordings typically need very long files, the careful administration of the resources being an important conditioning. Since it is widely used for EEG and sleep recording, its adaptation to code others signals used in the laboratory of Clinical Neurophysiology seemed a convenient goal. This was the reason to create EDF+. Basically, the difficulties came from the discontinuity of the signals used in many neurophysiological procedures (such as evoked potentials or nerve conduction studies) and from the introduction of a common system of annotation.

In the design of EDF+, together with the compatibility with EDF, giving the user as much freedom as possible was constantly in mind. So, any limit in aspects such as the number of channels, the precision of the time stamps, the length of the annotations and so on, were eliminated when it was possible. Whenever several possibilities appeared reasonable, the final decision was in the line of let the user decide.

Let us see some advantages of coding in EDF+:

• Possibility of storing very long segments of data (only limited by the capacity of the storing media).
• Possibility of storing a lot of signals.
• Unlimited sampling rate.
• Different sampling for each signal.
• Very compact storing derived from the fact that EDF+ uses exclusively 2-byte integers for data and UTF-8 for annotations. The differential sampling rate for each signal also makes the files more compact.
• Possibility of including time markers (that can act as internal or external triggers) of arbitrary precision in time.
• Possibility of including triggers outside the window covered by the data record (e.g., including a conditioning stimulus).
• Unlimited amount of trigger stamps, allowing the coding of very complex protocols of stimulation.
• Possibility of including XML (or other complex formats) inside the annotations.
• Possibility of storing continuous, discontinuous or even overlapping segments of data.
• Simplicity in the structure being easy to learn and to use
• Inclusion of data and annotations in the same file avoiding in most cases the use of several files to describe the same acquisition or analysis.
• Full independence of any manufacturer or supplier of medical instrumentation precluding arbitrary or strategic decisions.
• Full documentation of the format accessible on the Internet.
• High degree of compatibility with EDF, implying the easy exportation of previous tools and results.
• Possibility of internationalization of the annotations by using Unicode (encoded as UTF-8) inside the annotations.

In summary, the format was designed to make possible the filing and exchange of a wide range of physiological data, from the raw output of an A/D converter to the human analysis of the results after complex digital processing.

Let us see in practice how this fact is an intangible asset that makes your work easier. Imagine that you are a neuropsychologist trying to encode the acquisition signals for a protocol aimed to study the EEG evoked response to a very complex set of stimulus.

• The output of the A/D converter together with the code for each stimulus or the response of the experimental subject can be stored as an EDF+ file. This can be obtained with a lot of commercial instrumental devices handling the format (at least in EDF).
• You can edit the acquisition with a lot of software packages and convert the data from and to other formats allowing the use of a wide range of processing tools.
• From the acquisition file, you can extract a file containing only the acquisition epochs that are going to be included in the experiment.
• Imagine that you use some kind of averaging: the averages can also be stored in an EDF+ file together with, or separated from, the sweeps used to get the average.
• Your final results are stored as a grand average and standard deviation curves for different groups or stages. Eventually, you can use statistical analysis to compare different situations point by point. All these files can be coded in EDF+ format.
• You can use EDF software libraries to develop your own tools.
• The files containing the intermediate steps can be seen in a lot of different viewers worldwide (being some of them freely downloaded from the Internet). So, your development can be checked, criticized and improved by other people. Eventually, the software that you created can be used by other groups and your data can act as a benchmark for future developments.
• Your results will not be linked to any device or instrument.
• As a result of all these features, you do not have to reinvent the wheel when you design an experiment. The format is an ally that gives you new possibilities and tools, not a burden that limits the communication of your experiments.

Similar examples could be detailed for a physiologist coding some form of animal experiment, an electromyographer studying the evolution of some test according to the state of the disease in a patient, or a basic scientist developing models that have to be checked with real experiments.

If you are designing a commercial system, you can consider the possibility of exporting/importing data in EDF/EDF+. There are a lot of tools that can be used together with your device. On the other hand, if your device imports EDF/EDF+ data, many records in many different fields will be immediately accessible to check your instrument and to teach the users to practice with real examples.

A last example. It was taken from a recent article by Thomas Penzel et al. (Clin Neurophysiol 2002 Apr;113(4):571-8). Several sleep laboratories (25) decided to participate in a multicenter study where the sleep recordings were centrally scored. From these laboratories, 21 finally participated in the study, using 16 different systems. Ten systems exported recordings in EDF format, 2 systems allowed ASCII conversion and 4 allowed binary conversion. The listing of the different systems is included in the article. I would like to stress a sentence contained in the Results section: For 2 centers, the conversion problems could not be solved. Thus far, I do not know a similar study in EMG or EP.

EDF+ format mimics concepts used in the Clinical Neurophysiological laboratory. When you enter in Setup Mode in any modern device, you have to define things like filtering, number of signals, number of sweeps, window size, display amplification and so on. Most of these concepts can be directly translated to EDF+.

A very well designed format, however, is useless without a wide base of users. When users decide which tool are going to use the decision is not only taken based in technical reasons. Aspects such as easiness of learning, compatibility with the programming environment, formats used by their friends or colleagues and so on, also contribute to the decision. The design of a format is not necessarily a success if it obtains the applause of the experts or follows the criteria of a committee. It is a success if it is widely used and does not limit the possibilities of the people using it.

This propagandistic tutorial tries to familiarize non-programmer people with EDF+ format. It is not a normative document. The normative details can be found in Bob Kemp's site. In case of any difference, the normative document is right and this one is wrong. I think that the best way to learn EDF+ is by reading the examples of the normative document simultaneously with the text of the EDF+ protocol, having in mind your objectives. As soon as possible, try to begin to handle EDF+ files with your own tools (from editors to programming languages) or to create simple files containing sine waves, triangular waves and so on. If you are able to create a file that can be seen in an EDF viewer, I can foresee that you will become a zealot of EDF/EDF+. At least, I want to think that that will be the case. The examples included in the normative document cover a wide range of applications that could be similar to your needs. This tutorial only tries to give emphasis to some small details of the normative document in (I hope) a gentle way.

And now, let us go with the format. An EDF+ file is a set of data records (containing ordinary signals in binary format and annotation signals internally coded in UTF-8) with a header. Since EDF+ is based in EDF, the first chapters describe some facts on EDF. The next chapters describe the additions included in EDF+ and finally they describe the use of XML inside the annotations of EDF+.